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ES-I  INTRODUCTION  - THE  INCA  DATA  BASE  SYSTEM 
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As  the  scope  and  depth  of  Integrated  Nuclear  Communication  Assessment  (INCA) 
Program  analyses  have  grown  and  the  number  of  participants  in  the  field  has  increased, 
so  too  have  the  demand  for  and  the  amount  of  technical  data  grown.  Computer  Sciences 
Corporation  (CSC)  was  tasked  with  the  responsibility  of  studying  the  demand  and  usage 
of  INCA  program  data  and  recommending  a data  control/management  system.  The 
task  required  the  design  of  an  automatic  data  base  system  at  the  functional  and  detailed 
concept  levels,  and  the  toilowing  subtasks  comprised  the  work  breakdown  structure: 

1.  Survey  of  data  demand  and  usage 

2.  Preliminary  design 

3.  System  functional  requirements  and  specifications 

4.  Detailed  concept  design. 


The  first  two  subtasks  were  iterative  procedures  in  which  the  survey  produced 
information  suitable  for  a preliminary  design.  Questions  raised  during  the  preliminary 
design  phase  required  further  survey  effort.  The  last  two  steps  were  not  iterative  but 
followed  one  another  sequentially. 


This  report  presents  the  background  of  the  problem  brought  out  by  the  survey,  the 
purpose  and  objectives  of  the  required  data  base  system,  and  the  design.  For  clarity  and 
ease  of  understanding  of  the  INCA  data  base  architecture,  a section  on  functional  data 
base  component  fundamentals  is  also  presented.  This  report  also  includes  a basic  INCA 
analysis  support  data  base  system  established  at  the  Reston  facility  (DC EC)  of  the 
Defense  Communications  Agency  (DCA). 

Appendix  A of  this  report  contains  technical  system  information  concerning 
a prototype  INCA  data  base  system  used  to  test  the  concepts  presented.  Appendix  B 
provides  a tutorial  section  on  data  base  concepts  for  the  reader  unfamiliar  with  such 
concepts. 


ES-II  BACKGROUND  AND  SURVEY  RESULTS 

A CSC  survey  of  data  requirements,  data  repositories,  and  data  usage  by  the 
various  INCA  participants  initiated  this  task.  This  survey  took  the  form  of  compre- 
hensive discussion,  both  in  person  and  by  telephone,  with  the  INCA  organizations  as 
well  as  some  organizations  working  in  the  nuclear  effects  field  but  not  direct  INCA 
participants.  Since  the  efforts  of  both  INCA  and  non-INCA  participants  are  so  inter- 
related and  since  INCA  efforts  could  be  expanded  into  some  of  the  areas  researched  by 
non-INCA  organizations,  the  decision  was  to  have  the  data  management  system,  hence 
the  survey,  encompass  both  classes  erf  potential  users.  Table  ES-1  gives  the  list  of 
organizations  contacted  and  whose  data  bases  were  surveyed.  Figure  ES-1  illustrates 
the  relationship  of  the  various  data  classification  to  the  INCA  data  base  system. 
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Table  ES  - 1.  Data  Base  Survey  (Page  1 of  3) 


SERVICE  OR  COMPUTER  PROGRAM 


(CUSTODIA!1 


DESCRIPTION  OF  DATA  SETS/FILES 


INCAM-1  (BDM) 
ETC3 


DASLAC  (GE/ 
TEMPO) 


NET-2  (BDM) 

CIRCUS-2  (BOEING) 
SATL  (ESL) 


• Burst  Parameters 

• Communications  Sites 

• Table  Look-Up 

• Phenomenology 

• Systems,  Components,  Materials 

• Keywords 

• Current  Elements  (Resistors,  Capacitors) 

• Modelled  Devices  (Diodes,  Transistors) 

• Microcircuits 

• System  Elements 

• Circuit  Elements 

• Burst  Scenario 

• Satellite  Location  and  Parameters 

• Transmitter  Terminal  Parameters 


TROPO  (ESL) 


• Receiver  Terminal  Parameters 

• Scatter  Path  Locations 

• System  and  Antenna  Parameters 

• Transmitter  and  Receiver  Power 

• Antenna  Parameters 

• HF  Ray  Tracing 

• Ion  Distribution 

• Transmitter  and  Receiver  Locations 

• Burst  Locations  and  Altitude 
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Table  ES  - 1.  Data  Base  Survey  (Page  2 of  3) 


SERVICE  OR  COMPUTER  PROGRAM 
(CUSTODIAN) 

NUCOM  (SRI)  (Cont'd) 


WE  PH  (GE/ 
TEMPO) 


WRECS  (GE/ 
TEMPO) 

COMDEG,  DAFGEN 
(CCTC) 

NASTRAN  (CSC  AND 
OTHERS) 


TACVAM  (BOOZ- 
ALLEN) 

CSSM  (SAI) 


DESCRIPTION  OF  DATA  SETS/FILES 

• Neutron,  Beta,  Gamma  Fractions 

• Debris  and  Fireball  Descriptions 

• Ground  Loss  Coefficients 

• Weapon  and  Ray  Path  Parameters 

• Fireball  and  Debris  Properties 

• Temperatures  and  Electron  Densities 

• Natural  Atmospheric  Properties 

• Weapon  Parameters 

• Transmitter  and  Receiver  Locations 

• Blue  Strike/JAD  Data  Base 

1 

• Rods,  Beams,  Shear  and  Twist  Panels; 

Triangular  and  Quadrilateral  Shear; 
Bending  and  Plate  Elements; 
Axisymmetric  Shell  Elements,  Scalar 
and  General  Elements 

• Transmitter,  Receiver  and  Antenna 

Characteristics 

• Deployment  of  Tactical  Units 

• Sensor  Systems 

• Available  Weapons 

• Target  Arrays 


Table  ES  - 1.  Data  Base  Survey  (Page  3 of  3) 


SERVICE  OR  COMPUTER  PROGRAM 


DESC RIPTION  OF  DATA  SETS/FILES 


APACHE  SIMULATOR 
(GTE/SYLVANIA) 

ROSCOE  (GRC) 


• Circuit  and  Trunk  File 

• Uplink  and  Downlink  Parameters 

• Location  Data 

• Nuclear  Operation 

• Uplink  and  Downlink  Scintillation 

• Dynamic  Storage  Allocation  System 


Figure  ES-1.  INCA  Data  Classes 
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It  became  apparent  during  this  survey  that  two  data  base  systems  were  necessary, 
one  which  supports  the  technical  analysis  and  another  to  provide  a capability  for 
literature,  applicable  codes,  other  resources  searches,  or  inquiries.  The  first  data 
base  system  was  the  more  obvious.  The  many  INCA  participants  are  using  common 
data  and  some  are  generating  data  of  use  to  others.  A single  common  technical 
analysis  support  data  base  would  centralize  this  data  and  make  technical  data  elements 
available  to  all  users.  The  survey  concentrated  on  determining  what  data  elements 
and  data  files  should  be  included  in  the  centralized  system.  During  this  survey,  it  was 
also  apparent  that  many  of  the  participants  would  benefit  from  a second  data  base  system 
called  a resources  data  base.  Redundant  data  collection  efforts  could  be  reduced  or 
eliminated  in  the  areas  of  data  not  part  of  the  centralized  technical  analysis  support 
data  b;  se.  Keyword  searches  to  locate  data  sets,  documents,  personnel  expertise, 
etc. , in  the  nuclear  effects  field  could  be  performed  with  the  benefit  of  focusing 
attention  more  quickly  on  the  resource  required.  Addition  of  contracts,  agency, 
nuclear  effects  organization,  etc. , would  permit  inquiry  in  a variety  of  ways  suitable 
to  both  the  Defense  Nuclear  Agency  (DNA)  and  INCA  organizations  (e.g. , which  codes 
were  developed  by  a given  organization).  Prime  beneficiaries  are  new  DNA  contractors 
which  could  readily  assess  the  prior  research  done  and  concentrate  on  building  from 
this  point  rather  than  starting  in  a manner  which  duplicates  previous  efforts.  The  survey, 
therefore,  included  a collection  of  information  for  the  design  of  this  second  data  base 
system. 

Formal  names  have  been  given  to  these  data  bases:  Technical  Analysis  Support 
Data  Base  (TASDB)  and  Resources  Data  Base  (RDB). 

ES-HI  PURPOSE  OF  THE  INCA  DATA  BASE  SYSTEM 

The  single  reason  for  the  creation  of  the  INCA  data  base  system  is  the  centraliza- 
tion of  currently  developed  data  in  highly  useful  forms  to  prevent  duplication  of  effort  on 
the  part  of  INCA  Program  team  members  and  to  ensure  the  quality  of  data  used  for 
INCA  efforts.  Currently,  various  but  similar  data  files  and  data  bases  are  being  develop- 
ed by  contractors  with  little  knowledge  of  what  work  has  been  done  toward  creating 
their  required  data.  Usually,  project  teams  get  small  chunks  of  data  from  various 
sources  and  integrate  them  into  some  form  of  data  base.  What  is  finally  developed  is 
often  available  from  another  source  or  requires  only  a little  modification  to  make  it 
readily  useable.  This  exists  clearly  for  DCA  data  for  trunks,  circuits,  links,  equip- 
ments, etc.  In  varying  degrees,  this  is  also  true  for  phenomenology  data.  The 
problem  is  not  unique  to  the  INCA  Program  but  exists  almost  everywhere  in  the 
information  technology  field.  It  is  cost-effective  for  DNA  to  apply  data  base  technology 
and  the  discipline  of  centralization  to  the  INCA  Program. 

Usage  of  data  base  management  system  software  is  justified  by  several  conditions: 

I . The  large  volume  of  data  with  element  redundancy  (excess  storage  required) 
and  record  interrelationships 
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2.  A sizable  number  of  users  (especially  under  separate  authority) 

3.  The  need  for  a single  point  of  data  management 

4.  The  security/atcess  control  to  data  elements 

5.  Multiple,  simultaneous  users  of  the  data. 

Paragraph  ES-II  - Background  and  Survey  Results  reveals  that  these  conditions 
justifying  the  use  of  data  base  management  system  (DBMS)  software  have  been  met. 
Multiple  simultaneous  users  do  not  exist  now  since  each  organization  has  its  own  data 
copies.  However,  in  a centralized  operation,  there  will  be  multiple  simultaneous 
users  and,  hence,  there  will  be  additional  requirements  for  controlling  and  synchronizing 
their  activities  on  the  data  base.  DBMS  software  has  provision  for  permitting  multiple 
simultaneous  users  to  access  a common  data  base. 

ES-IV  OBJECTIVES  OF  THE  INCA  DATA  BASE  SYSTEM 

There  are  many  specific  objectives  which  could  be  cited  for  the  INCA  data  base 
system  design  once  it  has  been  established  that  the  purpose  for  creating  such  a data 
base  is  feasible  and  appears  cost-effective.  However,  for  the  initial  concept  work 
presented  in  this  report,  there  will  be  only  six  specific  objectives  as  described  below. 

Flexibility  of  the  architecture  permits  additions  and  integration  of  new  data  as 
users  find  the  INCA  data  base  system  useful  and  as  they  have  other  data  relatable  to  the 
current  content.  This  will  be  a necessity  for  the  Automated  Assessment  Tool  (A AT) 
which  will  be  evolving  over  the  next  years  and,  consequently,  will  have  changing  require- 
ments for  additional  data  integration. 

Flexibility  of  the  architecture  for  data  base  reorganization  is  important  since  the 
usage  patterns  of  the  data  base  and  the  internal  files  are  undefinable  at  this  time. 

Gross  tuning  and  later  fine  tuning  will  be  required  to  ensure  rapid  retrieval  and  to 
minimize  computer  resources  in  terms  of  Central  Processing  Unit  (CPU)  time  and  disk 
seek  times.  New  chains  may  have  to  be  added  to  facilitate  new  data  relationships  which 
will  be  identified  in  the  future.  Without  such  chains,  data  base  operations  might  consume 
a disproportionate  or  unnecessary  amount  of  CPU  resources. 

Ease  of  use  for  many  standard  reports  is  a specific  objective  which  has  two  issues. 
One  is  architectural,  requiring  that  common  data  relationships  be  identified  and  chains 
of  record  pointers  established  to  permit  all  request -relevant  data  be  immediately  and 
directly  available  without  significant  sorting  and  extracting.  The  other  is  implementation 
of  a simple  user  report  generator  which  can  permit  nonprogrammers  to  develop  reports 
from  the  data  base. 

Ease  and  assurance  of  data  maintainability  are  Influenced  partly  by  architectural 
and  partly  by  management  philosophy  (ensuring  that  maintenance  is  done  in  order  to 
assure  data  quality). 
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Finally,  there  must  be  a means  to  distribute  the  data  base  to  users,  either  as 
remote  or  local  batch  usage  of  the  data  base  on  one  computer  or  through  the  use  of 
tape /disk  distribution  to  users  for  their  own  computer  systems. 

These  specific  objectives  are  to  be  met  mostly  through  the  functional  and  detailed 
design  efforts.  While  the  foregoing  is  a reasonably  modest  set  of  specific  objectives 
imposed  on  the  INCA  data  base  system,  subsequent  contractual  work  and  use  of  early 
implementation  will  achieve  even  more. 

ES-V  INCA  COORDINATED  DATA  ENVIRONMENT 

Figure  ES-2  illustrates  the  order  and  control  over  data  sources  and  data  quality 
made  possible  with  a centralized  data  base  management  system.  Within  is  the  figure 
encompassing  all  aspects  of  the  INCA  Program,  the  shaded  area  separates  the  human 
aspects  from  the  automated  aspect  of  the  total  INCA  system. 

Starting  at  the  top  in  the  shaded  area  is  the  DNA  Project  Office  - INCA  Program. 
This  office,  through  contractual  instruments,  authorizes  INCA  participants  to  become 
users  of  the  INCA  data  base  system.  Application  software,  specific  to  the  analysis  to 
be  performed,  is  developed  by  the  users;  this  is  the  tool  which  the  user  employs  to 
enter  the  data  base  system.  The  software  may  be  used  to  reference  standalone  data  sets 
(files)  which  are  primarily  phenomology-oriented  data  or  procedures  to  involve  codes 
on  the  computer.  It  may  also  interface  to  either  of  the  two  data  bases  established. 
Interface  is  through  the  DBMS  which  accepts  a list  of  data  elements  to  be  referenced 
or  updated,  etc. 

In  the  unshaded  area  is  the  data  base  system  consisting  of: 

1.  The  data  base  administrator  who  receives  user  authorization  from  the  DNA 
Project  Office  and  general  guidance  as  to  how  the  data  base  is  to  be  used 

2.  The  DBMS  with  the  two  data  bases,  TASDB  and  RDB,  as  well  as  a data 
dictionary 

3.  A nuclear  codes  library 

4.  Standalone  data  sets. 

Users'  procedures  and  applications  programs  are  utilized  to  reference  the  codes 
library  and  standalone  data  sets  as  provided  by  the  standard  computer  operating  system. 
User  application  programs  access  the  two  data  bases  and  data  dictionary  (if  provided) 
through  the  DBMS.  It  controls  user  access  to  read,  write,  add,  and  delete  data 
elements;  users  may  be  authorized  for  one  or  several  of  the  options  by  the  Data  Base 
Administrator. 

The  Data  Base  Administrator  is  the  most  important  human  element  of  the  INCA 
data  base  system.  He  is  the  one  who  ensures  that  all  necessary  steps  are  taken  to: 
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INCA  COORDINATED  DATA  ENVIRONMENT 


Figure  ES-2.  INCA  Coordinated  Data  Environment 


1.  Set  authorization 

2.  Ensure  data  completeness 

3.  Ensure  data  quality 

4.  Fine-tune  the  system  for  efficient  use  of  CPU  resources  and  mass  storage. 

If  a well-experienced  person  is  not  chosen  for  this  position,  the  entire  data  base 
effort  could  be  a failure,  creating  more  problems  than  it  solves. 

ES-V1  FUNCTIONAL  DESCRIPTION  - TECHNICAL  ANALYSIS  SUPPORT  DATA  BASE 
SYSTEM 

A functional  description  is  developed  for  the  Technical  Analysis  Support  Data 
Base  System  (TASDB).  Scope  erf  this  functional  description  covers  the  following  areas: 

1.  The  information  content 

2.  Source  of  data  elements 

3.  Information  retrieval,  including  direct  access  and  indirect  access  (the  latter 
defined  as  requests  which  must  perform  relatively  extensive  processing 

on  directly  accessed  data  to  produce  a given  result). 

Content  of  the  TASDB  has  a communications  system  orientation  rather  than  nuclear 
phenomonological  orientation  and  is  based  on  the  Defense  Communications  System  (DCS). 
Data  will  be  maintained  for  the  following  communication  system  entitles: 

1.  Circuits 

2.  Trunks 

3.  Links 

4.  Nodes 

5.  Communications  paths 

6.  End-end  users  (routing) 

7.  Equipments 

8.  Facilities. 

Within  each  category  will  be  a record  for  each  individual  item  (e.  g. , a circuit, 
trunk,  facility,  etc.).  Such  records  contain  all  pertinent  technical  system  data  for  the 
individual  entity  as  well  as  a prespecified  number  of  bytes  for  general  usage  by  an 
AAT.  Such  bytes  will  be  used  by  the  AAT  as  required  to  record  the  effects  of  a scenario 
on  the  DCS.  By  independent  use  of  these  spare  bytes  in  each  record,  the  TASDB  is  kept 
in  tact  as  far  as  the  technical  system  information  is  concerned.  Therefore,  AAT  runs 
and  normal  inquiries  by  others  concerning  the  DCS  structure  can  proceed  simultaneously 
but  independently. 
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A detailed  conceptual  design  specification  was  developed  for  the  TASDB.  It 
includes: 

1.  Specifications  of  master  and  variable  files 

2.  Record  formats 

3.  Record  pointers  and  chains 

4.  CPU  memory  requirements. 

Figure  ES-3  illustrates  the  TASDB  architecture. 

ES-VIU  PROTOTYPE  INCA  TECHNICAL  ANALYSIS  SUPPORT  DATA  BASE 

To  test  out  the  concepts  developed  for  the  INCA  TASDB,  and  also  to  support  the 
Trunk  Allocation  Task,  a small  data  base  was  established  under  the  TOTAL  DBMS 
on  an  IBM-370/155  at  DCA  in  Reston,  Virginia.  Its  primary  content  is  a representative 
set  of  circuits  between  the  U.  S.  and  Europe,  as  well  as  in  Europe.  Included  are  all 
related  records  for  circuits,  trunks,  links,  and  sites/nodes.  Access  to  the  data  base 
permits  inquiries  to  show  all  circuits  contained  in  a given  trunk,  shows  all  trunks  and 
associated  circuit  file  for  trunks  passing  through  a given  node,  etc. 

The  results  of  the  Trunk  Allocation  Task  were  formally  briefed  to  DNA  and  the 
results  were  supported  by  the  data  base  usage.  If  it  had  not  been  developed,  repetitive 
sorting  would  have  been  required  to  align  records  from  one  file  to  those  of  other 
related  files  as  well  as  to  write  edit/select  utilities  to  extract  the  desired  data  from 
sorted  files.  Use  of  this  data  base  proved  the  utility  and  benefits  of  the  INCA  TASDB 
for  the  INCA  Program.  It  was  consequently  used  as  the  nucleus  of  the  larger,  more 
comprehensive  TASDB.  Refinements  to  this  prototype  were  made  prior  to  using  it  as 
a nucleus  to  the  TASDB.  Figure  ES-4  illustrates  the  prototype  TASDB  architecture. 

ES-IX  FUNCTIONAL  DESCRIPTION  - RESOURCES  DATA  BASE  SYSTEM 

A functional  description  was  developed  for  the  RDB.  The  scope  of  this  functional 
description  covers  the  following  areas: 

1.  Definition  of  the  data  base  files  with  regard  to  information  content 

2.  Information  access  capabilities  and  limitations. 

The  RDB  is  the  library  information  retrieval  subsystem  of  the  INCA  data  base 
system.  It  catalogs  reference  information  concerning  the  INCA  program,  including 
codes,  contracts,  documents,  etc.  With  the  RDB,  automated  information  reference 
regarding  previous  technical  efforts  and  available  resources  is  made  readily  available 
to  INCA  participants.  The  internal  RDB  architecture  will  be  designed  with  maximum 
flexibility  to  ensure  adaptibility  to  new  types  of  INCA  reference  and  resource  categories 
as  the  INCA  Program  develops. 
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Figure  ES-4.  Prototype  INCA  Technical  Analysis  Data  Base 


Content  of  the  RDB  will  initially  include  the  following  categories: 


I 


1.  Keywords 

2.  Documents 

3.  Codes 

4.  Data  bases  (including  data  files) 

5.  Contracts 

6.  Contractors/participants 

7.  Experts 

8.  Acronyms 

Within  each  category,  there  will  be  a record  for  each  entity.  Linkage  between 
interrelated  records  will  be  provided  to  make  efficient  and  quick  access  to  related 
information  as  a set  of  data. 

ES-X  DETAIL  DESIGN  SPECIFICATION  - RDB 

A detailed  conceptual  design  specification  was  developed  for  the  RDB.  It  includes 

1.  Specifications  of  the  master  and  variable  files 

2.  Record  formats 

3.  Record  pointers  and  chains 

4.  CPU  memory  requirements. 

Figure  ES-5  illustrates  the  RDB  architecture. 

ES-XI  CONCLUSIONS  AND  RECOMMENDATIONS 
ES-XI.  1 Conclusions  - TASDB 

The  TASDB  centralizes  the  data  repository  function  for  the  INCA  Program  as 
well  as  ensuring  the  quality  of  data  elements  used  in  technical  analyses.  A strong  data 
base  management  philosophy  should  be  adopted  to  assure  the  data  completeness  and 
quality  possible  with  an  automated  data  base  system.  Centralization  reduces  costs  of 
data  acquisition  for  new  and  continuing  INCA  participant  efforts.  Currently,  as  each 
new  project  has  significant  data  acquisition  costs  (e.g. , $50,000  to  $250,000),  new  data 
is  produced  by  analyses,  system  assessment  simulations,  etc. , it  will  be  fed  back  into 
the  data  base  system  to  serve  other  references  (assuming  the  results  are  of  general 
applicability).  No  definitive  quantitative  cost  estimates  of  savings  were  made,  but 
qualitative  considerations  from  a field  survey  show  that  there  currently  are  repetitive 
expenditures  for  similar  or  identical  data  collection  efforts. 
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Automated  data  base  systems  offer  cost  savings  primarily  through  economy  of 
sea  e effects.  For  INCA  data  used  in  support  of  technical  analyses,  this  economy  of 
scale  effect  is  present  in  the  forms  of: 

1.  Number  of  users 

2.  Large  volume  of  data 

3.  Highly  interrelated  system  data  for  which  a request  to  one  file  implies 
sorting  other  files  for  related  records 

4.  Data  redundancies  in  total  data  collection  due  to  duplicated  information  in 
different  files  of  INCA  interest. 

Data  base  systems  such  as  the  TASDB  can  reliably  and  effectively  handle  large 
volumes  of  data  for  multiple  users;  they  can  also  create  pointers  and  linkages  to  inter- 
connect related  data  elements /records  for  reduction  of  sorting  and  sifting  of  files 
and  to  eliminate  redundancy  of  data  insofar  as  it  is  efficient. 

Therefore,  cost  savings  to  the  INCA  program  are  considered  sizeable  and  will 
accrue  through: 

1.  One-time  centralization  of  data 

2.  Ongoing  minimal  cost  data  base  updating 

3.  Reduced  programming  requirements  (rn  I/O  file  coding  and  application 
independence  from  physical  data  storage) . 

ES-XI.  2 Conclusions  - RDB 

The  RDB  allows  a user  to  enter  specifics  about  requirements  (S’  a as  keywords 
nuclear  code  names,  participant  corporate  name,  etc.)  and  to  get  baca  data  showing 
what  resources  are  available. 

While  the  technical/economic  advantages  of  a DBMS  system,  per  se,  apply  for 
the  RDB  cited  above  apply  here  also,  the  justification  of  this  second  data  base  should 
be  mentioned.  With  each  new  INCA  contractor  and  new  project,  there  is  the  potential 
for  redundant  studies,  lost  manpower  due  to  finding  resources,  etc.  The  desired 
f°alA°f  any  continuing  program  is  to  build  upon  previous  results.  In  our  survey  of 

CA  participants,  such  costs  due  to  these  problems  were  observed,  and  it  was  concluded 
that  a management  information  system  (or  automated  catalog  of  resources)  is 
esirable.  The  functional  design  of  such  a data  base  and  its  usefulness  to  INCA  was 
then  developed  in  the  data  base  task. 

ES-XI.  3 Conclusion  - Selection  of  a DBMS 

CSC  examined  the  various  DBMS  software  packages  available,  concentrating  on 
their  internal  features  and  limitations,  flexibility,  ease  of  use,  and  computer  hardware 
on  which  the  S/W  can  be  used.  Comparisons  of  these  facets  were  measured  against 
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the  Government -furnished  DBMS  (called  TOTAL  and  marketed  by  Cincom  Systems,  Inc.). 
TOTAL  was  furnished  to  CSC  as  operational  on  the  IBM-370 /155  at  the  Reston,  Virginia, 
DCA.  It  was  used  for  the  Trunk  Allocation  Task  and  for  the  prototype  INCA  data  base 
effort.  Two  questions  were  to  be  answered  by  the  selection  process:  In  the  absence  of 
any  Government-furnished  DBMS,  which  DBMS  would  be  best  for  the  INCA  program? 

If  TOTAL,  as  provided  by  the  Government,  was  to  be  continued,  are  there  any  possible 
reasons  to  suggest  its  replacement  by  another  DBMS  ? 

The  answer  to  both  questions  is  TOTAL  as  DBMS.  It  is  the  best  available  package 
since  it: 

1.  Is  transportable  to  IBM,  Honeywell,  CDC,  and  many  minicomputers  in 
Government  inventory 

2.  Interfaces  to  standard  programming  languages 

3.  Is  easily  used 

4.  Has  great  flexibility  to  cost-effectively  handle  INCA  Program  emphasis 
changes 

5.  Is  widely  accepted  by  computer  industry 

6.  Has  good  vendor  support 

7.  Has  continued  development  of  online,  inquiry,  and  utility  S/W  modules. 

After  the  elimination  of  certain  inadequate  vendors,  those  examined  were: 


1.  System  2000 

2.  IMS 

3.  Model  204 

4.  IDMS 

5.  ADABAS. 


System  2000  would  be  the  next  best  choice  if  TOTAL  did  not  exist. 

ES-XI.  4 Recommendations 

CSC  recommends  that  a final  cost -benefit  analysis  be  made  to  measure  the  data 
base  system  concepts  and  design  generated  against  current  and  future  INCA  Program 
efforts.  This  is  not  anticipated  to  be  either  a lengthy  or  costly  study,  but  rather  to 
demonstrate  clearly  that  the  designed  data  base  system  is  clearly  cost-effective  to 
implement  at  this  time  or  at  a later  point  in  time. 

Assuming  that  the  analysis  proves  it  is  cost-effective  to  make  this  INCA  program 
investment  and  at  this  time,  CSC  recommends  that  the  DNA  take  strong  action  to 
establish  the  INCA  data  base  system  during  the  timeframe  shown  to  be  most  cost- 
effective  by  the  analysis  either  now  or  in  the  future. 
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We  make  this  recommendation  recognizing  that  the  DNA  and  the  INCA  Program 
are  long-term  entities  and,  therefore,  will  be  substantially  involved  in  repetitive 
data  collection  and  analysis  of  the  identical  or  similar  data,  differing  from  INCA  task- 
to-task  only  in  its  organization  and  usage. 

ES-XII  - DATA  BASE  TUTORIAL 

Appendix  B of  the  Final  Report  - Data  Base  Analysis  — provides  the  reader  with 
a generic  tutorial  description  of  a DMBS.  Data  files,  pointers,  chains,  and  other 
related  concepts  are  developed  in  a systematic  manner  to  illustrate  the  use  and 
benefits  of  a DBMS.  It  is  highly  recommended  that  readers  unfamiliar  with  DBMS 
operation  or  structure  review  this  appendix  prior  to  reading  the  technical  sections  of 
the  final  report. 


SECTION  1 - INTRODUCTION  - THE  INCA  DATA  BASE  SYSTEM 


As  the  scope  and  depth  of  INCA  Program  analyses  have  grown  and  the  number  of 
participants  in  the  field  has  increased,  so  too  has  the  demand  for  and  the  amount  of 
technical  data  grown.  CSC  was  tasked  with  the  responsibility  to  study  the  demand  and 
usage  of  INCA  program  data  and  to  recommend  a data  control/management  system. 

An  automatic  data  base  system  was  to  be  designed  at  the  functional  and  detailed  con- 
cept levels.  The  task  work  breakdown  consisted  of  the  following  subtasks: 

• Survey  of  data  demand  and  usage 

• Preliminary  design 

• System  functional  requirements  and  specifications 

• Detailed  concept  design. 

The  first  two  subtasks  were  iterative  procedures  in  which  the  survey  produced 
information  suitable  for  a preliminary  design.  Questions  raised  during  the  preliminary 
design  phase  required  further  survey  effort.  The  last  two  steps  were  not  iterative, 
but  followed  one  another  sequentially. 

In  this  report,  the  background  of  the  problem  as  brought  out  by  the  survey,  the 
purpose  and  objectives  of  the  required  data  base  system  and  the  design  are  presented. 

A basic  section  on  functional  data  base  components  is  also  presented  for  clarity  and 
ease  of  understanding  the  INCA  Data  Base  Architecture.  A basic  INCA  Analysis 
Support  Data  Base  System  which  was  established  at  the  Reston  facility  (DCEC)  of  the 
Defense  Communications  Agency  is  described. 

Appendix  A contains  technical  system  information  concerning  a Prototype  INCA 
Data  Base  System  used  to  test  the  concepts  presented.  Appendix  B provides  a tutorial 
section  on  data  base  concepts  for  the  reader  who  is  unfamiliar  with  such  concepts. 
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SECTION  2 - BACKGROUND  AND  SURVEY  RESULTS 


CSC  started  this  task  with  a survey  of  data  requirements,  data  repositories  and 
data  usage  by  the  various  INCA  participants.  This  survey  took  the  form  of  comprehensive 
discussions,  both  in  person  and  by  telephone,  with  the  INCA  organizations  as  well  as  some 
organizations  working  in  the  nuclear  effects  field,  but  which  are  not  direct  INCA  partici- 
pants. Since  the  efforts  of  both  INCA  and  non-INCA  participants  are  so  inter-related 
and  since  INCA  efforts  could  be  expanded  into  some  of  the  areas  being  researched  by 
non-INCA  organizations,  it  was  felt  that  the  data  management  system,  hence  the  survey, 
should  encompass  both  classes  of  potential  users.  Table  1 gives  the  list  of  organiza- 
tions contacted  and  whose  data  bases  were  surveyed.  Figure  2-1  illustrates  the 
relationships  of  the  various  data  classification  to  the  INCA  Data  Base  System. 

It  became  apparent  during  this  survey  that  two  data  base  systems  were  necessary, 
one  which  supports  the  technical  analysis  and  another  to  perform  literature,  applicable 
codes,  and  other  resources  searches  or  inquiries.  The  first  data  base  system  was  the  more 
obvious  and  the  one  toward  which  CSC  directed  its  efforts.  The  many  INCA  participants 
are  using  common  data  and  some  are  generating  data  of  use  to  others.  A single  common 
technical  analysis  - upport  data  base  would  centralize  this  data  and  make  technical 
data  elements  available  to  all  users.  The  survey  concentrated  on  determining  what 
data  elements  and  data  files  should  be  included  in  the  centralized  system.  During  the 
survey,  it  became  apparent  that  many  of  the  participants  would  also  benefit  from  a 
resources  data  base.  Redundant  data  collection  efforts  could  be  reduced  or  eliminated 
in  the  areas  of  data  not  part  of  the  centralized  technical  analysis  support  data  base. 

Keyword  searches  to  locate  data  sets,  documents,  personnel  expertise,  etc. , in  the 
nuclear  effects  field  could  be  performed  with  the  benefit  of  focusing  attention  more 
quickly  on  the  resource  required.  Addition  of  contracts,  agency,  nuclear  effects 
organization,  etc.  would  permit  inquiry  in  a variety  of  ways  suitable  to  both  the  DNA 
and  INCA  organizations  (e.g. , what  codes  were  developed  by  a given  organization). 

Prime  beneficiaries  would  be  new  DNA  contractors  which  could  readily  assess  the 
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Table  2-1.  Data  Base  Survey  (Page  1 of  3) 


SERVICE  OR  COMPUTER  PROGRAM 
(CUSTODIAN! 

INCAM-1  (BDM) 

ETC3 

DASIAC  (GE/ 

TEMPO) 

NET-2  (BDM) 


CIRCUS-2  (BOEING) 
SATL  (ESL) 

TROPO  (ESL) 


NUCOM  (SRI) 


DESCRIPTION  OF  DATA  SETS/FILES 

• Burst  Parameters 

• Communications  Sites 

• Table  Look-Up 

• Phenomenology 

• Systems,  Components,  Materials 

• Keywords 

• Current  Elements  (Resistors,  Capacitors) 

• Modelled  r-cvices  (Diodes,  Transistors) 

• Microcircuits 

• System  Elements 

• Circuit  Elements 

• Burst  Scenario 

• Satellite  Location  and  Parameters 

• Transmitter  Terminal  Parameters 

• Receiver  Terminal  Parameters 

• Scatter  Path  Locations 

• System  and  Antenna  Parameters 

• Transmitter  and  Receiver  Power 

• Antenna  Parameters 

• HF  Ray  Tracing 

• Ion  Distribution 

• Transmitter  and  Receiver  Locations 

• Burst  Locations  and  Altitude 
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Table  2-1.  Data  Base  Survey  (Page  2 of  3) 


SERVICE  OR  COMPUTER  PROGRAM 
(CUSTODIAN) 

NUCOM  (SRI)  (Cont’d) 


WE  PH  (GE/ 
TEMPO) 


WRECS  (GE/ 
TEMPO) 


COMDEG,  DAFGEN 
(CCTC) 

NASTRAN  (CSC  AND 
OTHERS) 


TACVAM  (BOOZ- 
ALLEN) 

CSSM  (SAI) 


DESCRIPTION  OF  DATA  SETS/FILES 

• Neutron,  Beta,  Gamma  Fractions 

• Debris  and  Fireball  Descriptions 

• Ground  Loss  Coefficients 

• Weapon  and  Ray  Path  Parameters 

• Fireball  and  Debris  Properties 

• Temperatures  and  Electron  Densities 

• Natural  Atmospheric  Properties 

• Weapon  Parameters 

• Transmitter  and  Receiver  Locations 

• Blue  Strike/JAD  Data  Base 

• Rods,  Beams,  Shear  and  Twist  Panels; 

Triangular  and  Quadrilateral  Shear; 
Bending  and  Plate  Elements; 
Axisymmetric  Shell  Elements,  Scalar 
and  General  Elements 

• Transmitter,  Receiver  and  Antenna 

Characteristics 

• Deployment  of  Tactical  Units 

• Sensor  Systems 

• Available  Weapons 

• Target  Arrays 
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Table  2-1.  Data  Base  Survey  (Page  3 of  3) 

SERVICE  OR  COMPUTER  PROGRAM  DESCRIPTION  OF  DATA  SETS/FILES 
(CUSTODIAN!  ~ 

• Circuit  and  Trunk  File 

• Uplink  and  Downlink  Parameters 

• Location  Data 

• Nuclear  Operation 

• Uplink  and  Downlink  Scintillation 

• Dynamic  Storage  Allocation  System 


APACHE  SIMULATOR 
(GTE/SYLVANIA) 

ROSCOE  (GRC) 


prior  research  done  and  concentrate  on  building  from  this  point  rather  than  starting 
in  a manner  which  duplicates  previous  efforts.  The  survey,  therefore,  included 
collection  of  information  for  the  design  of  this  second  data  base  system. 

Formal  names  have  been  given  to  these  data  bases;  Technical  Analysis  Support 
Data  Base  and  the  second,  Resources  Data  Base. 

2. 1 TECHNICAL  ANALYSIS  DATA  CLASSES 

Two  data  classes  were  identified  in  the  survey:  system  data  and  phenomenology 
data.  These  are  believed  to  be  the  only  classes  of  data  of  interest  to  the  INCA 
program  and  other  nuclear  effects  researchers  since  most  researchers  study  the 
nuclear  effects  of  one  or  more  detonations  on  the  performance  of  a single  communica- 
tions link  and  a smaller  set  study  the  effects  of  a detonation  on  a total  system  which 
currently  exists.  Data  in  both  classes  were  identified  and  analyzed  as  to  how  they 
are  used  by  current  codes  which  are  also  divided  into  system  and  phenomonology 
classes. 

System  data  consisted  of  such  files  as  circuit  files,  trunk  files,  link  files,  equip- 
ment files,  etc.  Such  elements  (or  data  records)  are  interrelated  in  describing  an 
architecture,  a complex  or  a system.  The  system,  in  this  case  a communications  sys- 
tem, can  be  exploded  into  component  parts  such  as  the  trunk  with  all  its  circuits  connect- 
ing two  geographic  points,  the  equipment  terminating  circuits/trunks,  etc.  The  "complex" 
may  be  studied  from  many  aspects  such  as  the  circuits  connecting  two  geographic  points, 
all  geographic  points  the  circuit  traverses,  all  trunks  supported  by  a microwave  tower 
at  a given  type  for  a specific  location,  etc.  This  gives  rise  to  a network  of  relationships 
between  distinct  data  records  and  consequently  use  of  one  record  (e.  g. , a trunk  record) 
may  require  locating  all  associated  records  (e.  g. , its  terminating  equipments,  or  its 
circuits).  A data  base  management  system  is  most  suitable  for  accessing  and  controlling 
the  data  and  its  inter-relationship  links.  Inter-relationship  links  between  distinct, 
but  related,  record  types  are  called  pointers  and  a series  of  pointers  such  as  those 
linking  all  circuits  to  its  given  trunk  record  is  called  a chain.  Use  of  such  pointers  or 
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chains  makes  rapid  retrieval  of  related  data  possible  without  sorting  or  sequential 
search.  It  is  also  more  efficient  than  a set  of  index- sequential  files.  Design  of  the 
data  sets  and  records  is  the  responsibility  of  the  data  base  administrator  and  system 
design  personnel.  Management  of  data  requests,  control  over  pointer  modification 
(e.  g. , as  required  in  additions,  deletions,  etc. ) is  related  to  data  base  integrity  and 
is  the  responsibility  of  a software  package  generically  known  as  a data  base  manage- 
ment system  (DBMS). 

Hie  other  data  class  is  sets  of  nuclear  phenomenology  data.  Such  data  is  used 
by  a model  input  or  generated  as  its  output.  Such  data  was  found  not  to  exhibit  the 
same  interrelationships  as  the  system  oriented  data.  This  data  involves  first  prin- 
ciples on  the  physics  of  the  event.  Individual  physical  effects  usage  is  their  chief 
characteristic.  In  terms  of  the  INCA  program,  it  is  recommended  that  such  data 
sets  be  centralized  for  ease  of  data  distribution,  but  would  be  treated  as  stand-alone 
data  files.  Examples  of  such  files  are: 

• Burst  parameters 

• Neutron,  Beta  and  Gamma  fractions 

• Ground  loss  coefficients 

• Fireball  and  debris  properties 

• Others 

2.2  RESOURCES  DATA  CLASS 

There  is  but  one  class  of  data  for  cataloging  INCA  program  resources.  It  is 
subdivided  into  data  files  similar  to  the  subdivision  of  system  data  (described  above) 
into  circuit  file,  trunk  file,  equipment  file,  etc.  Subdivisions  of  this  data  class  are: 

• Keywords 

• Documents 

• Codes 


2-7 


• Data  Bases/Sets 

• Contract 

• Contractors/Participants 

\ 

• Experts 

Examination  of  available  resources  and  discussions  with  INCA  and  non-INCA 
participants  showed  these  subdivisions  to  be  entirely  adequate  to  provide  information  or 
source  on  any  resource  required.  A description  of  the  subdivisions  is  not  necessary 
since  the  content  of  each  is  self-explanatory  by  the  title.  A very  significant  amount  of 
inter-relationships  between  subdivisions  exists.  For  instance,  a contract  record  could 
be  interlinked  to  all  document  records  for  documents  produced  under  the  contract. 
Similar  record  interlinking  could  occur  for  codes,  data  bases,  etc.  A given  company 
name  and  address  would  appear  in  many  records  and  could  be  condensed  to  a reference 
to  the  contractors/participant  file.  Inquiries  would  reference  one  file  (e.g. , contract 
number)  and  then  attempt  to  locate  all  documents,  codes,  etc. , developed  under  that 
contract  number  or  using  a keyword,  enter  that  file  and  attempt  to  locate  all  codes  or 
data  file  references  in  the  appropriate  Codes  or  Data  Base/Sets  file. 

As  with  the  system  data,  there  will  be  a series  of  pointers  or  data  chains  which 
will  "a  priori"  set  up  all  the  meaningful  relationships  that  inquiries  would  require. 
Management  of  these  chains  and  as  a result,  assured  data  base  integrity,  can  only  be 
provided  by  a data  base  management  system.  Therefore,  a DBMS  is  recommended  for 
the  Resources  Data  Base.  It  is  to  be  noted  that  this  is  a second  data  base  system  main- 
tained entirely  separate  from  the  system  data  base. 

2.3  BACKGROUND  AND  SURVEY  SUMMARY 

In  summary,  it  was  found  that  twe  Jdta  bases  are  required.  One  is  used  to  main- 
tain system  data  for  technical  analysis  and  simulation  efforts  such  as  the  assessment 
tool,  while  the  second  is  a library-oriented  data  base  for  inquiry  about  resources 
available.  Standard  phenomenology  data  is  best  kept  as  individual  data  sets  co-located 
at  one  centralized  source  under  a computer  system  data  librarian  function.  Codes  will 
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be  maintained  in  standard  computer  program  library  formats  for  source  and  object 
versions.  Collectively,  these  elements  constitute  the  INCA  Data  Base  System. 

It  Is  recommended  that  all  four  elements  cited  above  be  maintained  at  one  central 
facility  to  ensure  data  distribution  and  quality  control.  Distribution  can  take  the  form  of 
remote  usage  of  the  central  facility  (assuming  appropriate  crypto  and  security  measures 
are  available)  as  well  as  batch  processing  at  the  central  facility.  For  local  usage  by 
contractors,  copies  of  the  data  bases,  data  sets,  codes,  etc.  can  be  provided  on 
magnetic  tape  or  disk. 


SECTION  3 - PURPOSE  OF  THE  INCA  DATA  BASE  SYSTEM 


A single  reason  exists  for  the  creation  of  the  INCA  Data  Base  System:  centraliza- 
tion of  currently  developed  data  in  highly  useful  form  to  prevent  duplication  of  effort  on 
the  part  of  INCA  contractors  and  to  ensure  the  quality  of  data  used  for  INCA  efforts. 
Currently,  various  but  similar  data  files  and  data  bases  are  being  developed  by  con- 
tractors with  little  knowledge  of  what  work  has  been  done  toward  creating  their  required 
data.  Usually,  contractor  personnel  get  small  chunks  of  data  from  various  sources 
and  integrate  it  into  some  form  of  data  base.  What  is  finally  developed  is  often  available 
from  another  contractor  or  requires  only  a little  modification  to  make  it  readily  useable. 
This  exists  clearly  for  the  DCA  data  for  trunks,  circuits,  links,  equipments,  etc.  In 
varying  degrees,  this  is  also  true  for  phenomenology  data.  The  problem  is  not  unique 
to  the  INCA  program,  but  exists  almost  everywhere  in  the  information  technology  field. 

It  is  cost-effective  for  DNA  to  apply  data  base  technology  and  the  discipline  of  centraliza- 
tion to  the  INCA  program. 

Usage  of  data  base  management  system  software  is  justified  by  several  conditions: 

• Large  volume  of  data  with  element  redundancy  (excess  storage  required)  and 
record  interrelationships 

• More  than  a few  users  (especially  under  separate  authority 

• Need  for  single  point  of  data  management 

• Security /access  control  to  data  elements 

• Multiple,  simultaneous  users  of  the  data 

These  conditions  which  justify  the  use  of  data  base  management  system  software 
were  shown  to  be  met  as  outlined  under  Section  2 - Background  and  Survey  Results. 
Multiple,  simultaneous  users  do  not  exist  now  since  each  organization  has  its  own  data 
copies.  However,  in  a centralized  operation,  there  will  be  multiple,  simultaneous  users 
and  hence,  the  additional  requirement  for  controlling  and  synchronizing  their  activities 
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on  the  data  base  arises.  DBMS  software  has  provision  for  permitting  multiple, 
simultaneous  users  to  access  a common  data  base. 


; 


There  are  many  specific  objectives  which  could  be  cited  for  the  INCA  Data  Base 
System  design  once  it  has  been  established  that  the  purpose  of  creating  such  a data 
base  is  feasible  and  appears  cost-effective.  However,  for  the  initial  concept  work 
presented  in  this  report  , six  specific  objectives  were  established  and  are 
described  below. 

Flexibility  of  the  architecture  permits  additions  and  integration  of  new  data 
as  users  find  the  INCA  Data  Base  System  useful  and  have  other  data  relateable  to  the 
current  content.  This  is  a particular  necessity  for  the  Automated  Assessment  Tool 
(AAT)  which  will  be  evolving  over  the  next  years  and  consequently,  will  have  evolving 
requirements  for  additional  data  integration. 

Flexibility  of  the  architecture  for  data  base  reorganization  is  important  since 
the  usage  patterns  of  the  data  base  and  the  internal  files  are  undefinable  at  this  time. 
Gross  tuning  and  later  fine  tuning  will  be  required  to  ensure  rapid  retrieval  and  to 
minimize  computer  resources  in  terms  of  CPU  time  and  disk  seek  times.  New  chains 
may  have  to  be  added  to  facilitate  new  data  relationships  which  are  identified  in  the 
future.  Without  such  chains,  data  base  operations  might  consume  a disproportionate 
or  unnecessary  amount  of  CPU  resources. 


Ease  of  use  for  many  standard  reports  is  a specific  objective  which  has  two  issues. 
One  is  architectural  which  requires  that  common  data  relationships  be  identified 
and  chains  of  record  pointers  be  established  to  permit  all  data  relevant  to  a request 
to  be  immediately  and  directly  available  without  significant  sorting  and  extracting. 

The  other  is  implementation  of  a simple  user  report  generator  which  can  permit  nonr 
programmers  to  develop  reports  from  the  data  base. 

Ease  and  assurance  of  data  maintainability  is  partly  architectural  and  partly  a 
management  philosophy  (which  ensures  the  maintenance  is  done  in  order  to  assure  data 
quality). 
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Lastly,  there  must  be  a means  to  distribute  the  data  base  to  users  either  as 
remote  or  local  batch  usage  of  the  data  base  on  one  computer  or  through  the  use  of 
tape/disk  distribution  to  users  for  their  own  computer  systems. 

These  specific  objectives  are  to  be  met  mostly  through  the  functional  and  detail 
design  efforts.  While  the  foregoing  is  a reasonably  modest  set  of  specific  objectives 
imposed  on  the  INCA  Data  Base  System,  subsequent  contractual  work  and  use  of  early 
implementation  will  produce  further  objectives. 


SECTION  5 - INCA  COORDINATED  DATA  ENVIRONMENT 


A data  base  system  interfaces  people  and  data  in  a single  environment. 

Figure  5-1  shows  the  relationship  of  DNA,  the  INCA  participants,  the  INCA 
Data  Administrator  and  the  INCA  data.  This  system  level  schematic  applies  to  both  the 
INCA  Resources  Data  Base  and  the  INCA  Technical  Analysis  Support  Data  Base. 

The  shaded  area  of  Figure  5-1  contains  the  human  elements  of  the  system 
which  are  DNA  and  the  data  base  users  authorized  by  DNA.  At  the  top  of  the  system  is 
the  DNA  Project  Office/INCA  Program.  All  policy  decisions  regarding  data  base  user 
authorization,  data  bases  maintained/data  content  which  should  be  available  to  further 
quality  technical  analyses,  specific  directives  as  to  what  data  sources  may  be  used  to 
establish  or  increase  data  holdings  are  made  at  this  level.  Two  linos  of  authority  flow 
from  this  level:  one  to  authorize  INCA  participants  to  use  the  data  base  and  the  other 
to  the  INCA  Data  Administrator  who  is  the  guardian  of  the  INCA  Data  Base  System. 

Users  (represented  in  the  shaded  area)  use  application  software  (real-time  or 
batch)  to  access  the  INCA  Data  Base  System  for  data  retrieval.  There  are  three  categories 
of  information  which  can  be  retrieved  and  three  mechanisms  are  utilized.  Codes  are 
stored  within  the  computer  operating  system  program  library  and  are  retrieved  (or 
executed)  according  to  operational  procedures  of  the  operating  system.  Data  sets 
contain  look-up  tables,  parameters  sets  and  other  data  not  oriented  toward  a record- 
record  relationship  between  data  files.  These  are  also  accessed  according  to  standard 
operating  system  procedures.  Application  programs  are  required  for  this  type  of 
access.  Data  base  system  controlled  files  are  accessed  by  the  users  applications 
programs,  but,  unlike  data  sets,  the  application  programs  are  not  required  to  be  coded 
with  awareness  of  what  record  formats  are  or  provide  logic  to  correlate  records  (e.g. , 
all  circuits  records  of  the  circuit  file  with  the  trunk  record  of  the  trunk  file).  The  DBMS 


has  all  such  formats,  relationships,  etc.,  built  in. 


DNA  PROJECT  OFFICE 
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Figure  5-1.  INCA  Coordinated  Data  Environment 


The  sroond  line  of  authority  from  the  DNA  Project  Office  flows  to  the  INCA  Data 
Administrator.  This  individual  can  be  either  a DNA  staff  member  or  a contractor 
staff  member  if  a contract  is  issued  for  maintenance  and  operation  of  the  INCA  Data 
Base  System. 

Responsibilities  of  the  INCA  Data  Administrator  are: 

• Establish  the  data  base 

• Control  the  quality  of  data  from  supplier  sources 

• Ensure  a timed  system  which  is  efficient  in  terms  of  data  retrieval  and  updating 

• Control  passwords  and  other  security  aspects  of  the  INCA  Data  Base  System. 

Users  will  have  little  interaction  with  the  data  administrator.  His  prime  interaction 
(and  that  of  his  system  staff)  is  with  the  DBMS  and  the  data  files.  As  the  INCA  program 
evolves  and/or  changes  emphasis,  the  nature  of  the  retrievals  will  change  and  most 
likely  the  organization  of  the  data  base  itself.  This  results  in  re-tuning  the  system  by 
modifying  the  number  of  pointers  (new  record  relationship),  reorganizing  the  data  files 
or  changing  the  physical  storage  units.  Other  aspects  of  the  responsibilities  as  given 
above  are  self-explanatory. 

The  unshaded  area  of  Figure  5-1  illustrates  the  data  base  system  itself.  It  is 
composed  of  the  DBMS  software  package,  a data  dictionary  and  the  data  files  used  for  the 
two  data  bases  of  the  INCA  program. 

All  user  application  programs  interface  to  the  data  base  bv  means  of  the  DBMS. 

Lists  of  data  elements,  action  to  be  performed,  etc.,  are  passed  from  the  application 
program  to  the  DBMS.  If  the  action  requested  by  the  user  is  authorized  (determined 
from  user  characteristic  tables),  the  DBMS  performs  the  indicated  retrieval  or  update 
and  passes  the  results  back  to  the  user  application  program.  Therefore,  there  is  the 
interface  and  security  check  subsystem  as  well  as  a file  access  area  within  the  DBMS. 

The  above  make  up  the  totality  of  the  dynamic  INCA  Data  Base  System  environment. 


SECTION  6 - FUNCTIONAL  DESCRIPTION  - TECHNICAL  ANALYSIS 


This  section  sets  forth  the  functional  description  of  the  Technical  Analysis  Support 
Data  Base  System  (TASDB).  Scope  of  this  functional  description  is  extended  to  the 
following  areas. 

• Information  content  of  the  Technical  Analysis  Support  Data  Base  (TASDB) 

• Source  of  Data  Elements 

• Information  retrieval  including  direct  access  and  indirect  access  (the  latter 
being  defined  as  requests  which  must  perform  relatively  extensive  processing 
on  directly  accessed  data  to  produce  a given  result). 

A detail  design  specification  in  this  report  presents  the  data  files,  inter-file  linkages, 
records  formats,  etc. , as  would  be  required  to  implement  the  TASDB. 

6.1  CONTENT  OF  THE  TASDB 

Content  of  the  TASDB  has  a communications  system  oriented  rather  than  nuclear 
phenomonological  orientation.  Data  shall  be  maintained  for  the  following  communica- 
tion system  entities: 

• Circuits 

• Trunks 

• Links 

• Nodes 

• Communications  paths 

• End-end  users 

• Equipments 

• Facilities 

Within  each  entity  category  will  be  a record  for  each  individual  item  (e.g. , a 
circuit,  trunk,  facility,  etc.).  Such  records  contain  all  pertinent  technical  system 
data  for  the  individual  entity  as  well  as  a pre-specified  number  of  bytes  for  general 
usage  by  an  Automated  Assessment  Tool  (AAT).  Such  bytes  will  be  used  by  the  AAT 
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as  required  to  record  the  effects  of  a scenario  on  the  Defense  Communications  System. 
By  independent  use  of  these  spare  bytps  in  each  record,  the  TASDB  is  kept  in  tact  as 
far  as  the  technical  system  information  is  concerned.  Therefore,  AAT  runs  and  normal 
inquiries  by  others  concerning  the  DCS  structure  can  proceed  simultaneously,  but 
independently. 

6. 1. 1 Circuit  Data 

Circuit  data  maintained  and  accessible  in  the  TASDB  will  include  data  as  generally 
found  in  the  DCA  Circuit  File  and  described  by  DCA  circular  365-10-1. 

6.1.2  Trunk  Data 

Trunk  data  contained  within  the  TASDB  will  include  data  elements  as  generally 
found  in  the  DCA  Trunk  File  and  which  are  fully  described  in  DCA  Circular  310-65-1. 

6. 1. 3 Link  Data 

Link  data  contained  within  the  TASDB  will  include  data  elements  as  generally 
found  in  the  DCA  Links  File  which  are  fully  described  in  DCA  Circular  310-65-1. 

6.1.4  Nodes  Data 

Data  maintained  for  each  node  (switch  site,  microwave  tower  site,  and  user  site 
etc.)  will  include  the  following  elements: 

1.  Abbreviated  geographic  on-site  name  (according  to  DCA  abbreviation 
conventions) 

2.  Full  geographic  spelling  of  the  above  name 

3.  Full  spelling  of  geographic  location 

4.  DCA  area  code 

5.  DCA  county /state  codes 

6.  Latitude/longitude 

7.  Principal  functional  use  of  site  (e.  g. , AUTODIN  switch) 
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8.  Secondary  functional  use  of  site 

9.  Territory  function  use  of  site  (other  levels  may  be  added) 

10.  Site  plan  number 

11.  Site  plan  location 

6.1.5  Communications  Path  Data 

While  a circuit  describes  the  communications  path  from  one  geographic  point  and 
end  user  to  another,  the  communication  path  will  describe  the  path  of  the  circuit  in 
detail.  Path  data  begins  with  the  main  distribution  frame  or  tech  control  at  one  site 
and  traces  the  circuit  through  other  facilities,  cables,  trunks,  links,  etc.,  to  the 
destination  main  distribution  frame,  tech  control  or  other  termination  point.  Circuit 
data  maintained  in  the  TASDB  and  cited  above  only  describes  the  circuit  end-to-end 
parameters  as  a summary  of  the  end-to-end  capabilities  of  the  circuit  but  does  not 
show  the  detailed  flow  of  the  circuit  through  facilities,  cables,  trunks,  etc.,  as  does 
the  communications  data.  It  is  possible  for  several  circuits  to  have  the  exact  identical 
path.  Therefore,  several  circuit  CCSD  numbers  of  the  circuit  data  will  point  to  the 
same  path  number  when  the  path  is  identical  for  those  several  circuits. 

Data  elements  for  the  communication  path  data  have  been  developed  by  Computer 
Sciences  Corporation  using  the  DCA  circuits,  trunks  and  links  file  plus  the  MERL 
equipment  files. 

6.1.6  Equipment  Data 

Equipment  data  is  drawn  from  the  DCA  MERL  Equipment  file  and  organized  to 
fit  the  requirements  of  the  TASDBin  order  to  relate  equipment  to  nodes,  circuits, 
trunks  and  links. 

6.1.7  Facilities  Data 

Facilities  data  is  similar  in  nature  to  that  found  In  DCA  Circular  365-10  and  as 
used  In  the  DCA  files.  Data  elements  included  are: 
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• Facility  code 

• Full  spelling  of  facility  name/type 

• Links  to  where  these  facilities  are  used  on  circuits,  trunks,  links  or  in  nodes. 

6.2  ORGANIZATION  OF  TASDB 

The  organization  of  the  TASDB  is  that  of  a plex  or  network  structure  rather  than 
tree  (heirarchical)  or  relational  data  base  organizations.  Relational  data  base 
organization  is  mostly  theoretical  work  at  the  present  time  and  is  ruled  out  for  this 
reason.  A tree  or  heirarchical  organization  is  not  possible  with  the  differing  points 
of  view  of  data  base  access  required  by  the  INCA  participants.  Any  one  data  view- 
point can  be  used  to  create  a tree  structure  for  the  TASDB,  but  would  result  in  a high- 
ly inefficient  usage  for  another  participant's  viewpoint.  Typical  opposing  viewpoints 
would  be  considering  communication  paths  to  be  the  root  of  the  tree  and  branching 
downward  with  circuits,  trunks,  links,  etc.,  as  shown  in  Figure  6-1.  Another  user 
might  need  to  consider  end-end  circuits  as  the  root  of  a tree  and  differently  set 
up  the  downward  branching  of  the  remaining  data.  A plex  or  network  structure 
permits  all  the  data  to  be  interrelated  efficiently  for  any  viewpoint.  As  a consequence, 
no  tree  structure  exists  with  the  physical  organization  of  the  data,  but  a highly  inter 
linked  set  of  data  files.  Any  user  might  enter  the  network  (without  requirement  for 
any  concern  for  how  the  network  is  set  up)  and  his  usage  might  be  traced  as  either 
a tree  or  network  laid  out  on  the  physical  network  of  inter-related  data  files. 

6.3  TASDB  CAPABILITIES 

This  subsection  describes  the  various  access  techniques  to  the  data  held  in  the 
TASDB  and  information  access  capabilities  of  the  TASDB.  In  general,  a user  may 
enter  the  data  base  at  any  of  the  major  data  categories  described  above  and  view  the 
remaining  data  as  being  heirarchically  oriented  below  that  level.  The  subsequent 
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Figure  6-1.  Types  of  Data  Base  Systems 


subsections  describe  the  various  major  data  categories  in  turn  and  their  access  to 
the  sub-oriented  data. 


It  is  to  be  noted  that  all  requests  to  a data  base  are  processed  through  an  applica- 
tions package  as  shown  in  Figure  5-1.  These  can  be  user  written  for  specific  retrieval 
operations  or  can  be  general  purpose  inquiry  packages  which  assist  a user  to  formulate 
inquiries.  Such  packages  have  an  awareness  of  the  data  base  structure  and  are  able  to 
operate  reasonably  efficiently  in  a general  purpose  environment.  Design  of  the  TASDB 
has  been  guided  by  the  fact  that  both  types  of  access  to  the  TASDB  will  be  used.  The 
general  purpose  inquiry  package  will  permit  INCA  participants  to  obtain  circuit  routings, 
communication  paths,  node  equipment  lists,  etc.,  for  specific  entities.  Such  inquiries 
would  be  required  by  analysts  configuring  specific  circuits,  trunks  or  other  for  nuclear 
survival  hypothesis  testing,  etc.  Specialized  application  software  will  be  developed 
for  use  in  generating  periodic  reports  of  the  communications  system  configurations 
during  periods  of  analysis,  performing  specialized  searches  not  easily  performed 
by  a generalized  inquiry  package  or  for  communication  system  and  scenario  modeling. 

6.3.1  Specific  Functional  Capabilities 

6.  3. 1.1  Circuits 


TheTASDB  will  provide  access  to  a parameter  of  a circuit  from  end-to-end.  It 
will  be  possible  to  break  out  circuit  segments,  determine  trunks,  nodes,  associated 
equipments,  as  well  as  all  other  paths  which  traverse  the  same  communication  path. 
Channel  pack  data  can  also  be  obtained,  but  with  the  aid  of  the  application  program 
being  required  to  identify  that  a given  circuit  is  a channel  pack  and  to  request  the 
other  lower  speed  circuits  in  the  channel  pack. 

6.3. 1.2  Trunks 

TASDB  provides  all  DCA  data  on  trunks  and  relates  a trunk  record  to  all  circuits 
of  its  circuit  file  as  well  as  the  transmission  links  used.  Through  cross  references 
in  the  TASDB,  nodes,  equipments  networks  related  to  the  trunk  can  be  identified. 
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6. 3.1.3  Links 


Given  a link  identifier,  all  trunks,  circuits  nodes,  associated  equipments  related  to 
to  the  link  can  be  retrieved.  Networks,  communications  paths  and  number  of  circuits 
dependent  on  the  links  can  also  be  identified. 

6. 3.1.4  Networks 

Using  the  appropriate  identifier  for  any  network  (e.g. , AUTODIN,  CRITICOMM, 
etc. ) it  is  possible  to  identify  all  circuits,  communications  paths,  trunks,  links,  nodes 
and  equipments  involved  with  the  given  network. 

6. 3. 1. 5 End-to-End 

Given  any  pair  of  end-to-end  geographic  points  or  users  (providing  such  data  is 
supplied  for  data  base  initialization),  it  is  possible  to  identify  all  circuits,  trunks, 
links,  communications  paths,  equipment  and  network  associated  with  the  specified 
end-to-end  pair  of  geographic  locations. 

6. 3. 1. 6 Communications  Path 

The  communications  path  file  describes  every  path  (circuit  flow)  taken  by  a 
circuit.  Shown  are  equipments,  facilities,  nodes,  trunks,  links,  cables,  etc.  If 
more  than  one  circuit  takes  the  same  path,  then  the  path  is  maintained  exactly 
once  in  the  communications  path  file.  Using  the  communications  path  file,  it  is 
possible  to  identify  all  components  of  the  path  as  well  as  descriptions  of  the  equipment, 
numbers  of  and  identification  of  circuits  using  the  path,  the  networks  involved  and  the 
end-to-end  users  or  locations  for  the  path. 

6.3. 1.7  Sites 

Given  a specified  site  or  sites,  references  can  be  made  to  equipments  at  the 
site  (type,  manufacturer,  description)  trunks,  circuits,  links  and  communications 
paths  passing  through  the  site.  Further  information  can  be  obtained  by  referencing 
the  indicated  circuits,  trunks  etc.  to  determine  if  these  entities  are  not  available, 
what  networks,  users  or  geographic  pairs  are  not  available  for  communications 
because  of  the  results  of  a particular  scenario. 
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6. 3.1.8  Equipments 


Using  the  DCA  MERL  number,  military  nomenclature  or  Federal  Stock  Number, 
inquiry  can  be  made  into  the  TASDB  to  determine  where  the  specific  equipment  is 
located,  what  circuits,  trunks,  links  utilize  it  and  what  networks,  end-end  users  or 
geographic  points  are  supported  by  that  equipment. 

6.4  REFINED  INQUIRY  PROCESSING 

There  will  undoubtedly  be  inquiries  more  complex  than  those  cited  above.  For 
example,  instead  of  requesting  one  or  more  specified  circuits,  only  a count  of  the 
number  of  circuits  qualifying  to  some  parameter  value  may  be  desired.  A request 
might  be  required  which  lists  circuits  by  restoration  priority,  etc.  The  TASDB  can 
not  be  organized  to  satisfy  directly  every  request  conceivable.  Rather  it  is  structured 
to  relate  entities  one  to  another.  Some  requests  can  be  directly  satisfied:  obtain  all 
parameters  of  circuit  x.  Others  may  require  retrieving  all  circuits  and  examining 
their  record  content  to  see  if  some  parameter  value  is  present  and  then  list  those. 

Such  inquiries  might  be  termed  indirect  inquiries  or  refined  inquiry  processing. 

Applications  programs  are  required  to  provide  user  interface  to  the  DBMS  for 
direct  requests.  In  the  case  of  indirect  (or  refined  processing)  inquiries,  the  ap- 
plication program  must  also  provide  the  additional  logic  to  process  a set  of  direct 
requests  which  provide  the  application  program  with  the  data  necessary  to  perform 
the  refined  processing  in  satisfaction  of  the  original  inquiry.  Reference  manuals 
for  the  DBMS  used  in  the  TASDB  will  describe  how  this  is  done  in  detail  for  each 
of  the  major  programming  languages  (COBOL,  FORTRAN  etc.). 
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SECTION  7 - TECHNICAL  ANALYSIS  SUPPORT  DATA  BASE  (TASDB)  - 
DETAIL  DESIGN  SPECIFICATION 


In  this  section,  the  detail  design  of  the  Technical  Analysis  Support  Data  Base  is 
specified.  Depth  of  the  design  specification  is  carried  to  the  level  of  file  definitions, 
file  record  formats,  inter-file  pointers  for  chaining  records  of  one  file  to  related 
records  of  another  file  and  file  volume  estimates.  Volume  estimates  are  considered  to 
be  guideline  values  and  must  be  determined  during  the  implementation  phase  when  the 
most  current  volume  data  is  available. 

7. 1 DATA  BASE  MANAGEMENT  SYSTEM 

TOTAL  (manufactured  by  Cincom  Systems,  Inc.,  Cincinnati,  Ohio)  has  been 
selected  as  the  data  base  management  system  under  which  the  TASDB  is  developed. 
Operation  shall  be  6- mode  (as  it  is  termed  by  Cincom  Systems,  Inc.)  which  permits 
cross- region  intercommunication  with  only  one  copy  of  TOTAL  resident  to  serve 
multiple  simultaneous  batch  or  real-time  applications.  Core  requirements  are  tenta- 
• tively  estimated  at; 

• TOTAL  nucleus  code  14K  bytes 

• Buffer  I/O  area  30K  bytes 

• File  control  area  9K  bytes 

53  K bytes 

Buffer  I/O  area  is  estimated  as  6K  bytes  per  buffer  per  file  active  in  any  one  inquiry. 

At  this  time,  there  appear  to  be  five  files  active  simultaneously  for  the  worst-case 
inquiry.  File  control  area  requires  500  bytes  per  file  in  the  TASDB.  There  are  eighteen 
files  in  the  TASDB  architecture. 

Cincom  Systems,  Inc.,  utility  software  which  should  be  procured  with  TOTAL 
include: 

• Back-up  Utility  - to  checkpoint  the  entire  data  base  as  of  a certain  date. 

Backup  and  recovery  are  areas  of  major  concern  in  an  installation  operating 
under  a data  base  management  system.  The  CINCOM  recovery  utility 
ensures  restoral  of  "before"  images. 
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• Hi-Speed  Unload-Load  Utility  - permits  one  or  more  files  of  the  data  base  to 
be  copied  to  another  storage  device,  reformatted  as  required,  and  then 
reloaded.  This  function  is  useful  when  changing  the  record  format  of  a file 
by  data  element  addition,  deletion  or  re-arrangment,  etc.  The  remainder  of 
the  data  base  need  not  be  disturbed.  No  chains  of  pointers  are  lost  in  this 
process  and  after  reloading  the  file,  the  pointers  of  all  files  to  this  file  and 
reverse  are  in  proper  order. 

• Print,  Modify /Statistics  - This  utility  performs  two  functions:  (1)  the  data 
base  administrator  (DBA)  can  inspect  any  data  element  or  record  in  the  data 
base  and  modify  it  is  necessary,  (2)  the  DBA  can  obtain  data  base  and 
component  file  utilization  statistics  which  permit  the  DBA  to  five  times  the 
operating  efficiency  of  the  system. 

• SOCRATES  - a report  generated  which  can  be  easily  and  readily  used  by 
programmers  and  non-programmer  personnel  to  quickly  obtain  reports  from 
the  Data  Base.  It  is  a batch  mode  package. 

7.2  TASDB  COMPUTER  HARDWARE 

Current  planning  for  the  TASDB  requires  that  it  be  operational  on  a DEC  PDP-ll/70 
computer  system  since  specification  envisions  implementation  of  the  TASDB  on  a 
PDP-ll/70  at  Computer  Sciences  Corporation,  Falls  Church,  Virginia.  (Note  - TOTAL 
and  application  programs  are  transportable  to  IBM,  Honeywell,  CDC  computers  and 
several  other  minicomputers.  DEC  equipment  is  not  a specific  TOTAL  requirement). 
Primary  storage  devices  for  the  data  base  files  will  be  on  DEC  RP04  disk  storage  units 
having  an  approximate  storage  capacity  of  88  million  bytes  each. 

The  TASDB  design  is  not  sensitive  to  these  equipments  and  other  units  such  as 
a different  computer  or  disk  storage  units  may  be  utilized.  The  only  requirement  is 
that  sufficient  disk  storage  be  on-line  to  hold  the  entire  TASDB  when  it  is  to  be  used 
and  that  additional  disk  storage  or  a tape  drive  be  available  to  log  TASDB  updates  which 
are  required  for  reconstruction  of  the  TASDB  in  the  event  that  a previous  checkpoint 
copy  to  the  TASDB  must  be  used. 
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7.3  TASDB  DATA  FILES 

Under  TOTAL,  there  are  two  kinds  of  files:  Master  files,  which  are  entered  using 
a keyword  to  retrieve  a unique  item  (e.  g. , a circuit  record)  and  variable  files  which 
contain  further  descriptive  data  or  data  related  to  more  than  one  master  file  (e.  g. , a 
cross-reference  file  which  links  two  distinct  master  files  together  such  as  a circuits 
master  file  and  eight  variable  files  (seven  if  one  is  merged  with  a master  file)  in  the 
TASDB.  Figure  7-1  presents  the  TASDB  system  block  diagram.  Squares  represent 
master  files  and  hexagons  represent  variable  files.  It  can  be  easily  seen  that  master 
files  depend  on  variable  files  for  such  functions  as: 

• Cross-reference  to  other  master  files  in  a manner  similiar  to  the  DCS 
communications  structure  (e.g. , circuits,  trunks  and  links  have  definite 
relationships  to  each  other) 

• Sharing  of  common  information  (the  MERL  equipment  number,  A/N  nomen- 
clature and  Federal  Stock  Number).  Since  master  files  relate  all  common  items, 
information  such  as  description  and  manufacturer  can  be  shared. 

In  the  file  description  below,  the  file  name  for  programming  purposes  is  given  and 
follows  DCA  Hybrid  Simulation  Facility  file  name  conventions.  Four  characters  are 
used:  first  is  R to  indicate  a file  at  Reston;  second  is  M or  V to  indicate  a TOTAL 
master  file  or  variable  file;  the  two  remaining  characters  are  alphanumeric  and  are 
available  to  the  system  design  to  name  the  file  uniquely. 

7.3.1  Master  Files 

Eleven  master  files  are  specified  in  this  subsection.  Master  files  are  the  entry 
points  to  the  TASDB.  All  inquiries  must  start  at  a selected  master  file  and  can  then 
access  other  variable  and  master  file  records  to  link/point  to  related  records  in  variable 
files.  These  files  in  turn  can  point  to  other  master  files. 


7. 3. 1.1  Circuits  Master  File 
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Descriptive  File  Name  - CIRCUITS 
System  File  Name  - RMCK 
Pointers  to  Variable  Files: 

• Communication  Path  Detail  File  (RVPH) 

• Site  Equipment  File  (RVSE) 

• Circuit  Detail,  Trunk,  Network,  End-to-End  Cross-Reference  File  (RVXX) 
Access  Key  - CCSD  Identifier 

Purpose  - Contains  access  key  (circuit  identifier),  pointers  to  related  variable 
files  described  above  and  ten  spare  bytes  for  Automated  Assessment  Tool 
usage  during  scenario  analysis. 

User  enters  this  file  to  request  a specific  CCSD  and  as  required,  records 
from  the  related  variable  files. 

Proposed  File  Content; 

Data  Element 

DCA  CCSD  for  Circuit 
Pointer  to  major  cross  reference  RVXX 
Pointer  to  site  equipment  file  RVSE  - Site  1 
Pointer  to  communication  path  detail  RVPH 
Pointer  to  site  equipment  file  RVSE  - Site  2 
Spare  bytes  (for  AAT  use) 

7. 3. 1.2  Trunks  Master  File 

Descriptive  File  Name  - TRUNKS 
System  File  Name  - RMTR 
Pointer  to  Variable  Files: 

• Circuit  Detail,  Trunk,  Network,  End-to-End  Cross-Reference  File  (RVXX) 

• Trunk,  Link,  End-to-End  Cross  Reference  File  (RVLX) 

• Communications  Path  File  (RVPH) 

• Site  Equipment  File  (RVSE) 


Bytes 

8 File  Key 

8 
8 
8 
8 

10 
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Access  Key  - Trunk  Identifier 

Purpose  - Contains  trunks  data  for  each  trunk  of  DCS  and  permits  access  to  records 
of  related  links  in  given  trunk,  equipment  at  the  sites  terminating  the  trunk  and 
related  circuits  within  the  trunk.  It  is  possible  to  obtain  trunk  fill  by  following 
point  chain  in  the  circuit  detail,  trunk,  network,  end-end  cross-reference 
file  (RVXX).  All  links  composing  the  trunk  are  obtained  by  following  a pointer 
chain  in  the  trunk,  link,  end-end  cross-reference  file  (RVLX).  Each  record 
in  that  chain  contains  a link  identifier  and  pointer  to  the  link  record  in  the 
Links  Master  File  (RMLN).  Using  the  pointer  chain  to  the  records  in  the 
communication  Path  Detail  File  (RVPH),  all  communication  paths  related  to 
a given  trunk  can  be  found.  Ten  spare  bytes  are  provided  for  use  by  an 


Automated  Assessment  Tool. 

Proposed  File  Content  Data  Element  Bytes 

Trunk  identifier  6 file  key 

Pointer  to  Major  Cross-Reference  RVXX  8 

Pointer  to  Trunk- Link  Cross-Reference  RVLX  8 

Pointer  to  Comm.  Path  Detail  RVPH  8 

Direction  indicator  1 

Terminal  frame  location  8 

Facility  code  (from)  3 

State/Country  (from)  2 

Terminal  to  location  8 

Facility  code  (to)  3 

State/Country  (to)  2 

Service  availability  1 

Restoration  Category  1 

Package  System  Cross-Reference  (CCSD)  8 

Trunk  Capacity  4 
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Proposed  File  Content  Data  Element  (Cont'dl  Byt« 

Bandwidth  5 

From  Trunk  Terminal  Equipment  3 

To  Trunk  Terminal  Equipment  3 

Commercial  Radio  Group  Cross  Reference  ID  5 

Space  Bytes  (for  AAT  usage)  10 

7. 3.1.3  Links  Master  File 

Descriptive  File  Name  - LINKS 
System  File  Name  - RMLN 
Related  Variable  Files: 


• Trunk,  Link,  End-to-End  Cross  Reference  File  (RVLX) 

• Communications  Path  Detail  File  (RVPH) 

• Site  Equipment  File  (RVSE) 

Access  Key  - DC  A Link  Identifier 

Purpose  - Contains  DCA  link  parameters  primarily  for  each  link  in  the  DCS. 
Retrieval  of  a record  from  this  file  gives  link  data  plus  pointers  to  related 
termination  sites,  equipments,  trunks  supported  and  communications  paths 
supported.  Ten  spare  bytes  are  provided  for  use  by  the  Automated  Assess- 


ment Tool. 

Proposed  File  Content; 

Data  Element  Bytcs 

DCA  Link  Identifier  5 

Pointer  to  site  equipment  file  RVSE -Site  1 8 

Pointer  to  site  equipment  file  RVSE-Site  2 8 

Pointer  to  trunk-link  cross  reference  8 

Pointer  to  communication  detail  cross  reference  8 

Trailer  Terminal  Location  8 
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Data  Element  (Cont'd)  Bytea 

Facility  Code  3 

State/Country  2 

DC  A Area  Code  1 

Link  Control  Office  1 

Master  Group  Number  1 

Super  Group  Number  1 

Group  Number  1 

Trunk  Transit  or  Terminal  1 

Transmission  Medium  3 

Trunk  Cross-Reference  6 

Space  Bytes  (for  AAT  usage)  10 

7.3. 1.4  Network  Master  File 


Descriptive  File  Name  - Networks  File 
System  File  Name  - RMNT 
Related  Variable  Files: 

• Major  Cross-Reference  File  (RVXX) 

• Communication  Path  Detail  File  (RVPH) 

Access  Key  - Two  letter  network  identifier  characters  2-3  of  a circuit  CCSD) 


Purpose  - Contains  network  identifier  and  pointers  to  the  related  variable  files  in 
order  to  permit  quick  and  efficient  access  to  the  subset  of  circuits,  sites, 
equipments,  and  communication  path  detail.  Trunks,  links,  etc.,  which  are 
related  are  found  by  using  pointers  to  other  master  files  from  the  related 
variable  files  cited  above. 
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Data  Element 


Network  Identifier  (characters  2-3  of  CCSD) 

Pointer  to  Major  Cross  Reference  File  RVXX 
Pointer  to  Comm.  Path  Detail  File  RVPH 
Network  Name 

7. 3. 1.5  Site  Master  File 

Descriptive  File  Name  - Site  File 
System  File  Name  - RMSI 
Related  Variable  Files: 

• Facilities  File  (RvfcF) 

• Site  Equipment  File  (RVSE) 

• Major  Cross  Reference  File  (RVXX) 

Access  Key  - DCA  Abbreviated  Site  Name 

Purpose  - Contains  data  relevant  to  the  specific  site  as  well  as  pointers  to  the 
Facilities  File  (RVSF)  which  chains  all  facilities  (e.g. , MDF,  TCF,  etc.)  found 
at  that  site  and  to  the  Site  Equipment  File  (RVSE)  which  contains  sets  of  detail 
records,  one  per  each  piece  of  equipment  at  the  given  site.  Using  the  link  to  the 
Major  Cross  Reference  File  (RVXX),  all  circuits,  trunks,  networks  and  communi- 
cation paths  supported  can  be  located.  Links  dependent  on  that  site  are  located 


through  the  Trunks  File  (RMTR). 

Proposed  File  Content: 

Data  Element  Bytes 

Site  name  8 file  key 

Pointer  to  site  equipment  file  RVSE  8 

Pointer  to  facility  file  RVSF  8 

Pointer  to  Major  Cross  Reference  File  RVXX  8 

Full  Spelling  of  Site  Name  25 

Latitude  7 

Longitude  8 
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10 


file  key 
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Data  Element  (Cont’d) 

DCA  Area  Code 
DCA  Country  Code 
DCA  State  Code 
Facility  Description 
Vulnerability  Data 
Blast 
EMP 
Radiation 
Thermal 
Fallout 
Sabotage 
Restoral 
ECEMP 
SCEMP 
TREE 

Space  Bytes  (for  AAT  usage) 
7. 3. 1.6  Facilities  Code  File 


Bytes 

1 

2 

2 

20 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

10 
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Descriptive  File  Name  - Facilities  Code  File 
System  File  Name  - RMFC 
Related  Variable  File  (RVSF) 

• Facilities  File  (RVSF) 

• Communication  Path  Detail  File  (RVPH) 

Access  Key  - DCA  Facility  Code 

Purpose  - This  file  contains  a DCA  facility  code  abbreviation  and  pointers  to  two 
variable  files.  The  pointer  to  the  Facility  File  (RVSF)  will  chain  together  all 
sites  using  the  facility  class  for  rapid  identification  of  such  sites  while  the 
pointer  to  the  Communication  Path  Detail  File  (RVPH)  will  chain  together  all 
all  paths  using  the  given  facility  (and  through  reference  via  other  files,  related 
circuits,  trunks  and  links  can  be  found). 
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Proposed  File  Content: 

Data  Element  Bytes 

DCA  Facility  Code  3 file  key 

Pointer  to  Facility  File  RVSF  8 

Pointer  to  Communication  Detail  Path  File  RVPH  8 

7. 3. 1.7  Communications  Paths  Master  File 


Descriptive  File  Name  - Communications  Paths  File 
System  File  Name  - RMPH 
Related  Variable  Files: 

• Communications  Paths  File  (RVPH) 

Access  Key  - CSC  defined  path  nomenclature 

Purpose  - Using  the  path  identifier,  the  set  of  path  detail  records  in  the  variable 
file  (RVPH)  which  describe  the  path  can  be  located.  Extended  reference 
through  pointers  from  the  variable  file. 

Proposed  File  Content: 


Data  Element 

Path  Identifier 

Additional  Path  Identifier 

Pointer  to  Communication  Path  Detail  File 

Space  Bytes  (for  AAT  usage) 


7.3. 1.8  End-to-End  Master  File 


Descriptive  File  Name  - End-to-End  Index  File 
System  File  Name  - RMEE 
Related  Variable  Files: 

• Major  Cross-Reference  File  (RVXX) 

• Trunk-Link  Cross  Reference  File  (RVLX) 

• Communication  Path  Detail  File  (RVPH) 
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Bytes 

4 file  key 
3 
8 

10 
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Access  Key  - Concatenated  pair  of  geographic  points  or  end  user  identification. 
DCA  nomenclature  is  used  for  each  member  of  the  pair  and  the  lowest 
alphanumeric  element  is  used  as  the  first  member  of  the  pair. 

Purpose  - This  file  is  an  index  entry  to  permit  a user  to  use  two  geo- 
graphic points  (or  end  users)  to  access/ retrieve  all  circuits,  trunks, 
links,  communications  paths,  etc. , as  may  have  been  requested  by 
the  inquiry.  Use  of  this  index  file  as  an  entry  to  the  TASDM  merely 
provides  a more  efficient  method  of  retrieval  for  a frequently  expected 
inquiry  of  this  type.  With  more  burden  on  the  application  program, 
length  searches  could  have  produced  the  same  information  without 
using  disk  space  for  this  file. 

This  file  is  a good  example  of  providing  a master  file,  the  only  pur- 
pose of  which  is  to  intercept  a frequent  usage/inquiry  type  and  make 
desired  records  more  readily  available.  As  the  TASDB  usage  grows, 
there  may  be  justification  to  establish  more  such  master  files. 

Proposed  File  Content: 

Data  Element  Bytes 

2-triple  of  geographic/user  points  16  file  key 

Pointer  to  Major  Cross  Reference  File  RVXX  8 

Pointer  to  Trunk-Link  Cross  Reference  File  RVLX  8 

Pointer  to  Comm.  Path  Detail  File  RVPH  8 

7. 3. 1.9  MERL  Number  Master  File 

Descriptive  File  Name  - MERL  number  file 
System  File  Name  - RMMR 
Related  Variable  Files: 

• MERL  Cross  Reference  File  (RVMX) 

Access  Key  - DCA  MERL  number  of  specified  piece  of  equipment 
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Purpose  - An  index  Master  file  for  entry  using  the  MERL  number  to 
equipment  description  (standard  DCA  MERL  file)  and  to  be  able  to 
access  sites  at  which  that  equipment  can  be  found.  The  latter  is 
accessed  through  use  of  the  MERL  cross-f reference  file  to  obtain 
the  DCA  standard  nomenclature  and  then  access  can  be  made  to  the 
two  variable  files  containing  MERL  file  information  (RVMM  and  RVMD) 
and  to  the  site  equipment  variable  file  (RVSE) 

Proposed  File  Content: 

Data  Element  Bytes 

DCA  MERL  number  6 file  key 

Pointer  to  MERL  cross-reference  file  RVMX  8 

7.3.1.10  Federal  Stock  Number  Master  File 


Descriptive  File  Name  - FSN  File 
System  File  Name  - RMFS 
Related  Variable  Files: 

• MERL  Cross-Reference  File  (RVMX) 

Access  Key  - Federal  stock  number  of  the  specified  equipment 
Purpose  - Same  as  given  for  the  MERL  number  master  file  except  that  the 
federal  stock  number  is  used  as  the  entry  access  key. 

Proposed  File  Content: 

Data  Element  Bytes 

Federal  Stock  Number  11  file  key 

Pointer  to  MERL  Cross  Reference  File  8 


7-13 


7.3.1.11  Equipment  Nomenclature  Master  File 


l 

I 


Descriptive  File  Name  - Equipment  Nomenclature  File 
System  File  Name  - RMEN 
Related  Variable  Files: 

• MERL  Cross-Reference  File  (RVMX) 

• Manufacturer  File  (RVMF) 

• Site  Equipment  File  (RVSE) 

Access  Key  - Standard  DCA  equipment  nomenclature 

Purpose  - Using  the  nomenclature  (given  or  derived  from  given  MERL  number 
or  Federal  stock  number),  access  can  be  made  to  files  to  obtain  MERL 
number,  federal  stock  number,  equipment  description,  manufacturer  and 
sites  at  which  the  equipment  is  located.  This  file  contains  the  narrative 
description  of  the  equipment  as  well  as  the  nomenclature  key. 


Proposed  File  Content: 

Data  Element  Bytes 

DCA  nomenclature  20 

Pointer  to  MERL  cross-reference  RVMX  8 

Pointer  to  manufacture  file  RVMF  8 

Pointer  to  MERL  descriptive  data  RVED  8 

Equipment  description  30 

Vulnerability  Data  40 


7.3.2  TASDB  Variables  Files 

Variable  files  hold  information  common  to  one  or  more  master  files  as  well  as 
providing  a means  to  cross-reference  two  or  more  master  files.  Seven  variable  files 
are  used  in  the  TASDB  architecture. 


1 


7.3. 2.1  Major  Cross-Reference  Variable  File 


Descriptive  File  Name  - Major  Cross  Reference  File 
System  File  Name  - RVXX 

Purpose  - This  file  contains  DCA  circuit  parameters  for  each  circuit  and  has 
pointers  for  cross-reference  to  site  equipment,  sites  terminating  the  circuit, 
trunks,  the  network  circuit  is  part  of  and  the  end-to-end  user/geographic  points. 

Proposed  File  Content: 

Data  Element  Bytes 


Header  Record  From  Location  8 

State/Country  Code  2 

DCA  Area  Code  1 

Facility  Code  3 

Modulation  Rate  2 

Type  of  Operation  1 

Service  Availability  1 

Restoration  Priority  2 

Restoration  Priority  Cert.  1 

Security  Equipment  - Disection  1 2 

Security  Equipment  - Disection  2 2 

Trunk  Cross  Reference  6 


Segment  Record 
Terminal  Location 
State/Country  Code 
DCA  Area  Code 
Facility  Code 
Transmission  Pathway 
Channel  Number 
Type  of  Channel 


8 

2 

1 

3 

6 

3 

1 
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Bytes 


Multipoint  Flag  1 

Service  Availability  1 

Circuit  Control  Office  1 

Equalizer  Location  1 

Echo  Suppressor  Location  1 

Regen  Repeater  Location  1 

Type  of  Signaling  1 

Type  of  Segment  1 


Records  to  include  appropriate  pointer  chain  fields. 

7.3. 2.2  Communications  Path  Detail  Variable  File 

Descriptive  File  Name  - Communication  Path  Detail  File 

System  File  Name  - RVPH 

Purpose  - There  are  two  record  types  in  this  file.  Type  one  is  a header  record 
with  end-to-end  communication  path  data  (TOTAL  record  code  HD)  and  type 
two  records  which  are  a set  of  detail  records  describing  each  segment  of  the 
path  (circuit).  The  latter  are  identified  by  TOTAL  record  code  DT.  Using 
this  file,  cross  reference  can  be  made  to  further  detail  in  the  circuits  file 
(RMCK),  network  file  (RMNT),  end-to-end  user/geographic  point  file  (RMEE), 
links  file  (RMLN)  and  the  facility  code  file  (RMFC). 


Proposed  File  Content: 

Date  Element  Bytes 

Path  Header  Record 

Path  Identifier  12 

Associated  Network  8 

From  Location  17 

To  Location  17 
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Data  Element  Bytes 

Type  of  Service 

Spare  Bytes  (for  AAT  usage)  10 

Link  Record 

Link  Identifier  5 

Spare  Bytes  (for  AAT  usage)  10 

Records  to  include  appropriate  pointer  chain  fields. 

7. 3. 2. 3 Facility  Variable  File 

Descriptive  File  Name  - Facility  file 
System  File  Name  - RVSF 

Purpose  - This  file  contains  the  descriptive  information  on  the  facility  type  and 
contains  a chain  to  point  to  all  sites  at  which  that  facility  type  is  used. 

Proposed  File  Content: 

Data  Element  Bvtes 


Facility  Description  55 

Site  Plan  Number  15 

Site  Plan  Number  Location  15 

Spare  Bytes  (for  AAT  usage)  10 

Record  to  include  appropriate  pointer  chain  fields. 

7. 3.2.4  Trunk-Link  Cross-Reference  Variable  File 

Descriptive  File  Name  - Trunk  Link  Cross-Reference  File 
System  File  Name  - RVLX 

Purpose  - This  file  is  intended  only  to  cross-reference  trunks,  links  and 
terminating  geographic  sites  which  are  contained  in  Master  files. 

Proposed  File  Content: 

This  file  contains  only  pointer  fields  between  the  following  master  files: 
RMTR,  RMLN  and  RMEE. 


A 


7. 3. 2.  5 Site  Equipment  Variable  File 

Descriptive  File  Name  - Site  Equipment  File 

System  File  Name  - RVSE 

Purpose  - This  file  contains  sets  of  detail  records,  one  set  per  site.  Each  detail 
record  identifies  and  describes  an  equipment  at  the  given  site.  The  set 
header  record  contains  limited  information  about  the  site  and  full  site  detail 
information  is  contained  in  the  Site  Master  File  (RMSI).  Header  records  have 
a TOTAL  record  code  of  HD,  and  detail  records  have  a record  code  of  DT. 

Site  equipment  can  be  retrieved  as  a set  given  a site  and  pointer  from  the 
Site  Master  File  (RMSI).  A chain  of  a specific  equipment  type  for  all  sites 
pointer  to  by  a pointer  from  the  equipment  nomenclature  file  (RMEM)  is 
included.  This  permits  rapid  retrieval  of  all  sites  where  a specified 
equipment  is  found. 

Ten  spare  bytes  are  kept  in  each  detail  record  for  use  by  the  automated 
assessment  tool  in  deleting  or  degrading  equipment  during  scenario  processing. 


Proposed  File  Content: 

Data  Element  Bytes 

Equipment  nomenclature  (abbr)  12 

Use  Code  R = receive  1 

S = send 
P = power 
etc. 

Spare  bytes  (for  AAT  usage)  10 

Record  to  include  appropriate  pointer  chain  fields. 

7.3. 2. 6 MERL  Cross-Reference  Variable  File 

Descriptive  File  Name  - MERL  Cross-Reference  File 
System  File  Name  - RVMX 
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Purpose  - Equipment  nomenclature  is  used  to  access  equipment  at  sites  (files), 
manufacture  files,  and  the  equipment  description  file.  If  the  MERL  number 
or  federal  stock  number  is  used,  then  this  must  be  translated  via  this  MERL 
Cross-Reference  File  to  the  corresponding  nomenclature  in  order  to  access 
the  same  data,  but  using  one  of  the  other  two  identifications  as  an  inquiry 
access  method. 

Proposed  File  Content: 

Since  this  is  a cross-reference  file,  only  pointer  chain  fields  are  to  be  included. 

7. 3. 2. 7 Equipment  Manufacturer  Variable  File 

Descriptive  File  Name  - Manufacturer  File 

System  File  Name  - RVMF 

Purpose  - This  file  contains  data  concerning  the  manufacturer  of  one  or  more 
equipments.  While  it  could  have  been  maintained  in  the  equipment  nomen- 
clature records,  there  exists  the  possibility  of  several  manufacturers  for 
the  same  piece  of  equipment.  Therefore,  there  could  not  be  unique  records 
in  that  Master  file.  Consequently,  a variable  file  is  used  to  contain  these 
possible  sets  of  alternative  manufacturer  records  and  all  other  single  records 
as  well. 


Proposed  File  Content; 

Data  Element 

Manufacturer  code  (MERL) 

Manufacturer  name  and  address 

Record  to  include  appropriate  pointer  chain  fields. 


Bytes 


SECTION  8 - PROTOTYPE  INCA  TECHNICAL  ANALYSIS  SUPPORT  DATA  BASE 


To  demonstrate  the  concepts  and  detailed  design  of  the  INCA  Data  Base  System, 
a prototype  (but  operationally  useful)  data  base  describing  trans- Atlantic  communications 
has  been  created  by  CSC  using  the  TOTAL  data  base  management  system  on  an  IBM- 
370/155  at  DCA-Reston  (DCEC),  The  data  base  was  designed  as  a straightforward  model 
of  the  communications  networks.  In  accordance  with  DC  A data  base  naming  conventions, 
it  is  called  RFBTAC  (Reston,  batch  mode,  Trans-Atlantic  Communications).  RFBTAC 
exists  only  on  the  classified  data  system;  currently  an  unclassified  copy  is  being  created 
for  general  development  work.  Figure  8-1  is  a general  system  level  block  diagram 
of  the  data  base. 

8. 1 MASTER  DATA  FILES 

Four  master  files  were  created  to  reflect  the  four  major  components  of  the 
communications  system  (single  circuit  and  networks): 

• Trunks 

• Links 

• Circuits 

• Sites  (terminal  points  for  trunks,  links,  and  circuits) 

Each  record  in  a master  data  file  reflects  a single  trunk,  circuit,  link  or  site. 

Tables  A-l  through  A-6  in  Appendix  A describe  the  format  of  each  record  type,  as 
well  as  showing  TOTAL  system  control  links  (chains  of  pointers).  File  names  were 
selected  using  the  DCA  file  name  conventions;  for  example,  RMTR  is  the  trunk  file 
name  (Reston,  Master-file,  user  ID  such  as  trunks,  in  this  case).  Circuit  file  uses 
the  name  RMCT;  link  file,  RMLK  and  RMSI,  site  data  file. 

8.1.1  RMTR  - Trunk  Data  File 

The  records  of  RMTR  each  describe  an  individual  trunk  in  the  communication  system. 
Records  are  keyed  on  trunk  identification  code,  as  given  by  standard  DCA  nomenclature, 
with  the  additional  specification  of  service  availability.  This  allows  programmed 
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Figure  8-1.  Prototype  INCA  Technical  Analys: 


reroutes  to  be  listed  separately.  All  necessary  linkages  to  logically  relate  this  file  to 
both  variable  entry  files  (RVCT  and  RVTL)  are  contained  in  these  records.  Through 
the  variable  files  (used  as  cross-reference  devices),  trunk  related  circuit,  link  and 
site  information  can  be  rapidly  retrieved  from  the  corresponding  master  data  files. 

Information  in  a trunk  record  contains  the  following  data: 

• Record  key  (trunk  identifier  and  service  availability) 

• Trunk  operational  status  flag 

• Restoration  priority 

• Trunk  origination  site 

• Trunk  termination  site 

• Number  of  channels  in  trunk 

• Bandwidth 

• Number  of  channels  available 

• Facility  type  at  which  trunk  originates 

• Facility  type  at  which  trunk  terminates 

8.1.2  RMCT  - Circuit  Data  File 

Each  record  of  RMCT  summarizes  information  about  a circuit  which  is  contained 
in  the  trans-Atlantic  communications  networks.  Records  are  keyed  by  the  Command 
Communications  Service  Designator  (CCSD)  assigned  by  DCA  with  an  additional  specifica- 
tion of  service  availability.  This  allows  programmed  reroutes  to  be  distinctly  identified 
in  retrievals.  All  necessary  linkages  are  contained  to  relate  this  data  file  to  RVCT 
(a  cross-reference  device  to  access  relate  a circuit  to  its  trunk  and  to  site  information). 
Data  contained  in  each  record  consists  of: 

• CCSD  and  service  availability 

• Circuit  operational  status  flag 

• Restoration  priority 

• Point  of  origin 

• Point  of  termination 

• Type  of  circuit  routing  applied 


• Pseudo  trunk  usage  flag 

• Pseudo  trunk  cross-reference 

• Facility  of  origin 

• Facility  of  termination 

8.1.3  RMSI  - Site  Data  File 

Each  facility  at  each  site  within  the  trans- Atlantic  communications  network  is 
described  by  a record  in  RMSI.  The  location  name,  abbreviated  according  to  the  rules 
specified  by  DCA,  with  the  facility  code  appended  to  it  serves  as  the  record  key.  This 
file  contains  the  necessary  linkages  to  associate  sites  with  the  appropriate  records  in 
both  RVCT  and  RVTL,  providing  the  cross-references  to  related  circuit,  trunk  and  link 
information.  Information  contained  in  each  record  consists  of: 

• Abbreviated  location  name  and  facility  code 

• State  or  country  of  location 

• Site  operational  status  flag 

• Latitude/longitude  of  site 

8.1.4  RMLK  - Link  Data  File 

The  records  of  RMLK  contain  summary  information  on  each  link  in  the  network. 
They  are  keyed  by  the  DCA  assigned  link  identification.  Linkages  to  RVTL  are  provided 
affording  access  to  related  trunk  and  site  information.  Data  contained  in  each  record 
Includes: 

• Link  identification  code 

• Link  operational  status  flag 

• Transmission  media  code 

• First  endpoint  of  link 

• Second  endpoint  of  link 

• Type  of  facility  at  first  endpoint 

• Type  of  facility  at  second  endpoint 
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8.2  VARIABLE  ENTRY  DATA  FILES 


Master  aata  files  are  utilized  to  hold  information  concerning  each  of  the  four 
major  elements  of  the  trans -Atlantic  communications  system.  Variable  entry  data 
files  are  used  for  three  purposes  generally: 

• To  store  variable  numbers  of  detailed  records  relating  a single  master  record 
(in  the  case  of  an  order  entry  system,  the  master  file  might  contain  invoice 
header  information  and  the  variable  entry  file  might  contain  the  detail  records, 
one  for  each  item  ordered). 

• To  store  detail  information  which  relates  to  two  different  master  records  in 
two  distinct  master  data  files 

• To  serve  only  as  a cross-reference  device  to  go  from  one  master  data  set  to 
another  master  data  set 

In  the  prototype  INCA  Technical  Analysis  Support  Data  Base,  the  last  objective 
of  variable  entry  data  files  is  used.  Cross-referencing  between  the  four  master  data 
files  described  above  is  then  possible.  Each  of  the  two  variable  entry  data  files  contains 
pointers  to  the  records  it  cross  references.  It  provides  for  such  retrievals  as:  given 
the  trunk  master  record,  find  all  circuits  which  fill  the  trunk  (trunk  fill  request).  TTie 
two  variable  entry  data  files  are: 

• RVCT  which  cross-references  the  circuit,  trunk  and  site  master  data  files 

• RVTL  which  cross-references  the  trunk,  site  and  link  master  files 

Information  content  is  not  listed  for  these  files  as  they  contain  only  DBMS  pointers 
to  records  In  the  master  data  files  where  all  information  is  kept.  Appendix  A gives  the 
record  formats  of  both  variable  entry  files. 

8.2.1  RVCT  - Circuit.  Trunk  and  Site  Cross-Reference 

The  records  in  this  file  can  be  accessed  from  either  RMCT,  RMTR  or  RMSI. 

Each  record  lists  a circuit  and  the  trunk  carrying  it  at  the  given  site.  For  every  circuit 
in  the  network,  such  a record  is  provided  for  each  of  its  segments.  In  this  way,  all 
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the  trunks  employed  by  the  circuit  and  all  the  sites  it  traverses  are  listed.  Viewing 
these  records  from  another  perspective,  other  information  becomes  available.  For 
example,  at  each  site,  all  the  circuits  and  trunk  which  pass  through  it  are  enumerated. 

8.2.2  RVTL  - Trunk,  Link  and  Site  Cross-Reference 

The  records  in  this  file  can  be  accessed  from  either  RMTR,  RMLK  or  RMSI. 

Each  record  represents  a subsection  of  a trunk,  listing  the  trunk  identifier,  the  link 
carrying  it,  and  the  sites  forming  the  endpoints.  This  allows  easy  access  to  Information 
such  as  all  the  sites  a trunk  traverses  and  all  the  links  it  uses.  Similarly,  all  the  trunks 
carried  by  a link  or  all  the  links  at  a given  site  can  be  easily  obtained. 

8. 3 DATA  CODING 

Much  of  the  data  in  the  data  base  follows  standard  DC  A nomenclature  for  site  names, 
trunks,  parameters,  etc.  These  are  fully  explained  in  DC  A circular  DC  A 310-65-1. 
Appendix  A contains  a list  of  those  codes/abbreviations,  etc.,  which  are  used  by  the 
prototype  INCA  Technical  Analysis  Support  Data  Base.  Record  formats  given  in 
Appendix  A indicate  which  data  code  table  of  the  appendix  applies. 
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SECTION  9 - FUNCTIONAL  DESCRIPTION  - RESOURCES  DATA  BASE  (RPR 

This  section  sets  forth  the  functional  description  of  the  Resources  Data 
Base  (RDB).  Scope  of  the  functional  description  include: 

• Purpose  and  goals  of  the  Resources  Data  Base 

• Definition  of  the  data  base  files 

• Information  accessing  capabilities  and  limitations 

The  contents  of  these  areas  describe  the  functional  requirements  and  capabilities  of 
the  RDB.  Detailed  design  specifications  follow  in  subsequent  sections. 

9. 1 RDB  PURPOSE  AND  GOALS 

The  Resources  Data  Base  is  the  library  information  retrieval  subsystem  of  the 
INCA  Data  Base  System.  It  will  catalogue  reference  information  concerning  the  INCA 
program  including  codes,  contractors,  experts,  etc.  All  INCA  project  reference 
data  should  be  included. 

The  RDB  will  provide  automated  reference  information  to  INCA  personnel. 

By  use  of  this  data  base,  duplication  of  effort  should  be  significantly  reduced  and  as 
well,  new  INCA  contractors  can  quickly  locate  materials  which  set  a proper  starting 
posture  for  their  research  and  engineering  efforts.  The  data  base  is  designed  to  allow 
maximum  flexibility  within  the  confines  of  the  DBMS.  The  user  will  have  access  to 
INCA  reference  information  through  various  access  routes.  Included  in  the  data  base 
design  are  methods  for  file  cross  referencing.  This  permits  maximum  access  with 
minimum  of  redundancy. 

9.2  GENERAL  DESCRIPTION 
9.2. 1 Content 

Content  of  the  RDB  is  limited  to  INCA  reference  data.  Information  will  be 
maintained  under  the  following  categories: 


< 


1 


Key  words 


Documents 


Codes 


Data  bases 


Contracts 


Contractors/participants 


Experts 


Acronyms 


Within  each  category  will  be  a record  for  each  individual  entity.  Such  records 
will  contain  all  pertinent  reference  information  for  that  entity.  Linkage  between  the 
categories  will  be  provided  in  the  records  as  dictated  by  the  DBMS. 


9.2. 1.1  Keywords 


Keywords  facilitate  RDB  inquiries  by  linking  all  entities  which  relate  to  a given 
keyword  (e.g. , codes,  documents  etc.).  A listing  of  nuclear  phenomenology,  nuclear 
effects,  and  communication  systems  descriptors  and  identifiers  will  aid  the  user  in 
selecting  appropriate  keywords  for  a given  inquiry. 


9. 2. 1.2  Documents 


Documents  data  will  include  data  elements  that  describe  documentation  currently 
available,  relating  to  INCA.  This  documentation  can  include  code  descriptions,  users 
manuals,  nuclear  effects  reports,  et  al.  Typical  data  elements  included  are; 


Report  title 


Report  number 


Date  issued 


Page  count 


Security  classification 


Government  reference  numbers  - DDC  # - i.e.  AD  XXXXX 


Distribution  Restrictions 


Updates/revisions 
Author/ Company 


Report  Status  - Draft,  Final 


9.2. 1.3  Codes 


Codes  data  will  include  all  data  elements  describing  computer  codes.  Typical 
data  elements  included  are: 

• Code  name 

• Mathematical  models  (foundation  of  Theory) 

• Memory  requirements 

• Host  computer 

• Functional  description 

• I/O 

• Documentation  completeness 

• Usage  information  (Prerequisites,  Applications) 

• Update  revisions 

• Responsible  agency 

• Documentation 

9.2. 1.4  Data  Bases  (Other  than  INCA) 

Data  Base  data  will  include  elements  that  describe  current  data  bases  or  data 
sets.  Typical  data  elements  included  in  the  data  base  category  are: 

• Data  Base  name 

• Functional  description 

• Record  info 

0 D.  B.  M.  S. 

9. 2. 1.5  Contracts 

Contracts  data  will  include  elements  that  describe  INCA  contracts  related  to 
nuclear  effects  on  communications.  Typical  data  elements  relevant  to  contracts  include: 

• Contract  number 

• Let  date/ completion  date 

• Responsible  organization 

• INCA  WBS  elements  being  worked 

i 
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• Reports  published 

• Reports  scheduled  delivery  dates 


9. 2.1.6  Contractors 

Contractor  data  will  include  elements  that  describe  INCA  contractors.  Typical 
data  elements  include: 

• Contractor  name 

• Contractor  address 

• Contractor  telephone  number 

• INCA  affiliation 

• Contractor  program  manager 

9. 2.1.7  Experts 

Experts  data  will  include  data  elements  that  reference  personnel  with  nuclear 
assessment  expertise.  Such  expertise  shall  encompass  nuclear  phenomonology, 
nuclear  effects,  related  computer  codes,  et  al,  as  deemed  necessary  by  INCA. 
Typical  data  elements  relating  to  experts  include: 

• Expert  name 

• Expert  address 

• Expert  telephone  number 

• Associated  company/contractor 

• Area  of  expertise 

9. 2.1.8  Acronyms 

Acronym  data  will  include  all  acronyms  or  abbreviations  relating  to  any  subject 
included  in  this  data  base  followed  by  the  full  expanded  title  corresponding  to  that 
acronym  or  abbreviation. 

9.2.2  Data  Base  Organization 

The  organization  of  the  RDB  is  contingent  on  the  data  accessing  requirements  of 
the  user.  RDB  files  need  to  be  accessed  through  cross-reference  to  different  files. 


f 


Consequently,  RDB  files  must  be  able  to  interconnect  with  each  other.  Therefore, 
the  logical  structure  of  the  data  base  requires  a plex  or  network  design  as  opposed 
to  a hierarchical  design.  (Appendix  B discusses  types  of  data  bases).  Such  a 
logical  structure  permits  more  efficient  access  and  optimum  interrelationships  files. 

The  data  base  files,  however,  are  organized  hierarchically.  Their  design  is  discussed 
in  the  detailed  design  specification  section  of  this  report. 

9.3  RDB  CAPABILITIES  AND  LIMITATIONS 

This  subsection  describes  the  various  data  accessing  techniques  for  the  RDB 
including  capabilities  and  limitations.  The  data  base  design  criteria  were  produced  as 
a result  of  the  data  base  survey  results  and  suggested  user  requirements.  From  this 
background,  file  accessing  priorities  were  established  that  would  create  a comprehen- 
sive, efficient  data  base,  but  require  a minimum  of  redundant  information.  Such  a 
design  permits  maximum  accessing  capabilities,  limited  only  in  areas  where  direct 
record  access  need  is  minimal  and  information  could  be  easily  and  readily  available 
through  other  routes. 

9.3.1  Specific  Functional  Capabilities 

The  RDB  will  access  information  via  specific  major  categories  - keywords,  codes, 
contractors,  and  data  bases.  Other  information  can  only  be  accessed  through  a reference 
to  these  files  first. 

9. 3.1.1  Keywords 

The  RDB  will  provide  access  to  information  through  use  of  keyword  identifiers 
or  descriptors.  These  keywords  will  link  associated  documents  and  experts  directly. 
Other  related  information  must  be  accessed  via  a cross  reference  catalogue. 

9. 3. 1.2  Codes 

RDB  will  provide  access  to  reference  information  via  code  names.  The  code 
name  will  have  direct  access  to  associated  documents,  contracts,  and  experts. 

All  other  related  information  must  be  accessed  via  the  cross  reference  catalogue. 
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9. 3.1. 3 Contractors 


Contractor  name  is  another  access  route  to  RDB  information.  Direct  retrieval 
of  experts  to  contracts  is  possible  through  this  route.  All  other  related  information 
must  be  accessed  via  the  cross  reference  catalogue. 

9. 3. 1.4  Data  Bases 

Data  base  names  is  the  final  area  that  can  access  RDB  reference  information. 

It  will  directly  access  related  documents  or  reports.  Other  related  information 
must  again  be  retrieved  via  the  cross  reference. 

9.3.2  Specific  Limitations 

The  RDB  is  organized  such  that  some  information  cannot  be  directly  accessed. 
This  information  however  would  normally  be  desired  in  conjunction  with  information 
that  can  be  directly  accessed. 

Categories  included  in  this  limitation  are: 

• Documents 

• Experts 

• Contracts 

For  example,  information  about  personnel  could  normally  be  related  to  codes 
associated  with  that  person  or  contractors  subsidizing  the  person  or  keywords  that 
describe  the  area  of  expertise  of  the  person.  Experts  information  would  not  usually 
be  accessed  by  itself.  Therefore,  to  optimize  the  system,  experts  information  must 
be  accessed  via  other  specified  routes. 


SECTION  10  - RESOURCES  DATA  BASE  (RDB)  - DETAIL  DESIGN  SPECIFICATION 


This  section  specifies  the  detail  design  of  the  Resources  Data  Base.  The  Extent 
of  this  design  will  include  file  definitions,  file  content,  file  length  and  specifications, 
field  lengths  and  specifications,  inter-file  pointers,  and  data  base  memory  require- 
ments. All  volume  estimates  are  considered  to  be  guideline  values.  Final  deter- 
mination of  volume  must  occur  during  the  implementation  phase. 

10.1  DATA  BASE  MANAGEMENT  SYSTEM 

TOTAL  (manufactured  by  Cincom  System,  Inc.,  Cincinnati,  Ohio)  has  been 
selected  as  the  data  base  management  system  (DBMS)  under  which  RDB  is  developed. 
This  permits  incorporation  of  RDB  with  the  TASDB  under  one  DBMS. 

Core  requirements  are  tentatively  estimated  at: 

• Total  nucleus  code  Specified  under  TASDB 

• Buffer  I/O  area  24  K bytes 

• File  control  area  4.  5 K bytes 

Buffer  I/O  area  is  estimated  as  6K  bytes  per  buffer  per  file  active  in  any  one  inquiry. 
At  this  time,  there  appear  to  be  four  files  active  simultaneously  for  the  worst  case 
inquiry.  File  control  area  requires  500  bytes  per  file  in  the  RDB.  There  are  nine 
files  in  the  RDB  architecture.  For  further  discussion  of  TOTAL,  refer  to  Section 

7.1  (Data  Base  Management  System). 

10.  2 RDB  COMPUTER  HARDWARE 

For  RDB  operational  computer  hardware  specification,  refer  to  Section  7.2 
(TASDB  Computer  Hardware). 

10.3  RDB  DATA  FILES 

The  TOTAL  DBMS  defines  two  kinds  of  data  base  files:  Master  files  and 
Variable  files.  Master  files  required  a single  unique  keyword  to  identify  a record. 
Variable  files  have  no  keyword  limitations,  however  they  cannot  be  accessed  as  stand 
alone  files.  Variable  files  must  be  accessed  via  a master  file. 
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Figure  10-1  presents  the  RDB  system  block  diagram.  Master  files  are 
represented  by  rectangles  and  variable  files  are  represented  by  hexagons.  As  in 
the  TASDB,  variable  files  are  necessary  for  sharing  of  common  information  and 
cross  referencing  of  information  between  master  files. 

10.3.1  RDB  Master  Files 

The  RDB  design  specifies  five  master  files.  All  inquiries  must  start  at  a 
selected  master  file  which  then  can  access  other  variable  or  master  file.  The 
following  subsections  define  the  detailed  master  file  specifications  for  the  RDB. 

The  logical  file  structure  is  shown  in  Figures  10-2  through  10-5. 

10.3.1.1  Codes  Master  File 

Descriptive  File  Name  - Code  File 

System  File  Name  - RMCD 

Related  Variable  Files: 

• Documents  File 

• Experts  File 

• Contracts  File 

• I/O;  Functional  Description  File 

• Major  Cross  Reference  File 

Access  Key  - Code  Name  Acronym 

Purpose:  The  Codes  File  contains  information  related  to  specific  codes  as  well 
as  pointers  to:  the  Documents  File  which  contains  all  documents  and  reports 
related  to  the  code;  the  Experts  File  which  contains  all  personnel  familiar 
with  the  code;  the  Contracts  Fiie  which  usts  contractual  data  of  the  code; 
the  I/O  - Functional  Description  File  which  contains  inputs,  outputs  and 
functional  description  of  the  code;  the  Major  Cross  Reference  File  which 
links  the  code  with  Contractors,  Data  Bases  and  Keywords  Files. 


DOCUMENTS 


Figure  10-1.  RDB  File  Relationships 
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Figure  10-2.  Codes  File  Logical  Structure 
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Figure  10-3.  Contractor  File  Logical  Structure 


Keyword  File  Logical  Structure 


DATA  BASE: 


Figure  10-5.  Data  Base  File  Logical  Structure 


Proposed  File  Content: 
Data  Element 


■ 


mm 


Record  Field  Definition 

Code  Name  - the  code  acronym  (i.e. , SIDAC) 

Expanded  Code  Name  - the  full  title  of  the  code  (i.  e. , Single  Integrated 
Damage  Analysis  Capability) 

Host  Computers  - a list  of  computer  systems  for  which  the  code  has  been 
written  or  modified 

Program  Languages  - the  computer  language  utilized  in  the  code 

Memory  requirements  - the  memory  required  to  store  and  run  the  code  and 
its  results 

Agency /Office  - the  responsible  gov't  agency  and  office  (i.e.,  DCA/CCTC) 

Computer  Models  - the  mathematical  models  used  for  simulation  (i.e.,  - 
windage;  antenna  . . .) 

Updates/Revisions  - the  dates  of  the  four  most  recent  revisions  or  updates 
of  the  code 

Accuracy /Reliability  Info  - comment  as  to  the  accuracy  and/or  reliability 
of  the  code 

U sage  Info  - comment  as  to  the  extent  the  code  is  usee: 

Documentation  Completeness  Quotient  and  Date  of  Evaluation  - number  from 
1 to  10  approximating  the  extent  of  code  documentation  plus  the  date  of 
such  evaluation. 

Input  - a list  of  required  and  optional  inputs  for  a code 

Output  - list  of  standard  and  optional  outputs  for  a code 

Functional  Description  - abstract  of  the  purpose  and  function  of  the  code 


v f 
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10.3.1.2  Contractor  Master  File 


Description  File  Name  - Contractor  File 

System  File  Name  - RMCT 

Related  Variable  Files 

• Documents  File 

• Experts  File 

• Contracts  File 

• Major  Cross  Reference  File 

Access  Key  - Abbreviated  Contractor  Name 

Purpose:  The  Contractors  File  contain  all  relevant  information  regarding 
contractors  or  participants  who  are  or  have  been  involved  in  nuclear 
effects  on  communications.  Pointers  are  included  which  link:  documents 
and  reports  related  to  contractor;  Experts  File  which  chains  all  personnel 
with  a contractor;  Contracts  File  which  chains  contracts  associated  with 
a contractor;  Keywords,  data  bases,  and  codes  to  the  contractor  via  a 
Major  Cross  Reference  File. 


Proposed  File  Content 

Data  Element  Byte 

Contractor  Abbreviated  Name  8 

Pointer  to  Documents  File  g 

Pointer  to  Expert  File  g 

Pointer  to  Contracts  File  g 

Pointer  to  Major  Cross  Reference  File  g 

Contractor  Full  Name  30 

Contractor  Address  (Street,  City,  St)  35 
Zip  Code  • 5 

Contractor  Telephone  Number  10 

INCA  Participant  4 

Program  Manager  30 


File  Key 
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Record  Field  Definition 


Contractor  Abbreviated  Name  - abbreviated  name  of  contractor  to  be  used 
as  access  key 

Contractor  Full  Name  - Unabbreviated  name  of  contractor 

Contractor  Address  - Street,  City,  and  State  of  contractor 

Contractor  Telephone  Number  - associated  office  telephone  number 

INCA  Participant  - INCA  will  appear  if  the  contractor  is  an  INCA  participant 
otherwise  blank. 

10.3.1.3  Keyword  Master  File 

Descriptive  File  Name:  Keyword  File 

System  File  Name  - RMKW 

Related  Variable  Files 

• Documents  File 

• Experts  File 

• Major  Cross  Reference  File 

Access  Key  - Keyword 

Purpose:  The  Keyword  File  is  incorporated  in  the  Resources  Data  Base  as  a 
reference  file  so  as  to  allow  searches  for  codes,  expert  documents, 
contractors  and  data  bases  via  the  use  erf  word  identifiers  or  descriptors 
associated  with  records  in  the  various  files.  Conversely,  this  data  base 
design  can  allow  a listing  of  keywords  related  to  any  record  in  a file 
linked  to  the  major  cross  reference  file. 
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Proposed  File  Content: 


Data  Element  Bytes 

Keyword  18 

Pointer  to  Experts  File  8 

Pointer  to  Documents  File  8 


Pointer  to  Major  Cross  Reference  File  8 
10.3.1.4  Data  Base  Master  File 


File  Key 


Descriptive  File  Name:  Data  Base  File 

System  File  Name  - RMDB 

Related  Variable  Files 

• Documents  File 

• Contracts  File 

• Major  Cross  Reference  File 

Access  Key  - Data  Base  Name 

Purpose:  The  Data  Base  File  contains  the  name  and  related  information  of 
data  bases  which  are  associated  with  nuclear  effects  data  or  codes. 
Specifically  this  file  will  be  limited  to  nuclear  effects  on  communications 
data  bases  (and  data  sets).  The  file  is  also  designed  to  permit  data  sets 
of  codes  which,  although  not  technically  Data  Bases,  have  valid  tc  use- 
ful nuclear  effects  data.  The  Data  Base  File  will  have  pointers  to  the 
documents  file  for  data  base  reports  and  to  the  Major  Cross  Reference 
File  for  reference  to  associated  codes,  keywords,  and  contractors. 

Proposed  File  Content 

Data  Element  Byte 

Data  Base  Acronym  6 File  Key 

Pointer  to  Documents  File  8 

Pointer  to  Major  Cross  Reference  File  8 
Data  Base  Full  Name  20 
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Data  Element 

Number  of  Records 
Length  of  Records 
Element  List 
DB  Description 
DBMS 

Record  Field  Definition 


Byte 

5 

5 

To  be  determined 
To  be  determined 

11 


Data  Base  Full  Name  - the  expanded  name  of  the  data  base 

Number  of  Records  | the  data  base  storage  and  record  structures 

Length  of  Records  I are  defined 

Elements  List  - data  parameter  headings 

DB  Description  - abstract  of  the  purpose  and  function  of  the  DB 

DBMS  - comment  as  to  whether  the  Data  Base  Management  System  is 
commercial  or  proprietary 

10.3.1.5  Acronym  Master  File 

Descriptive  File  Name:  Acronym  File 
System  File  Name  - RMAC 
Related  Variable  Files:  None 
Access  Key  - Acronym 

1 

Purpose:  Many  technical  reports,  codes,  agencies,  etc.,  are  listed  by  their 
abbreviation  or  acronym.  The  Acronym  File  will  expand  acronyms  to  their 
full  title  if  requested  by  the  user.  It  will  act  as  a single  purpose  data  base 
and  cannot  be  accessed  via  any  other  files  in  the  RDB. 

Proposed  File  Content 

Data  Element  Bytes 

Acronym  (system,  agency,  code,  etc.)  12  File  Key 

Expanded  Title  50 
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10.3.2  RDB  Variable  Files 
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Variable  files  hold  information  common  to  one  or  more  master  files  as  well  as 
to  cross-reference  two  or  more  master  files.  The  RDB  uses  four  variable  files  in 
the  architecture  design.  Logical  file  structure  for  the  variable  files  is  shown  in 
Figures  10-6  through  10-8. 

10.3.2.1  Documents  Variable  File 

Descriptive  File  Name  - Document  File 
System  File  Name  - RVDC 

Purpose:  The  Documents  File  contains  a listing  of  documents  produced  for 
or  relating  to  the  keywords,  codes,  and/or  data  bases  specified  for 
the  INCA  Resources  Data  Base.  This  variable  file  is  therefore  logically 
to  be  accessed  by  the  Code  File,  Contractor  File,  Keyword  File,  and/ 
or  Data  Base  File. 

The  Documents  File  will  contain  report  title  and  number,  security  classifi- 
cation, and  other  associated  information  listed  below. 

Proposed  File  Content 


Data  Element 

Bytes 

Code  Name  (Acronym) 

8 

Key 

Contractor  Name  (Abbrev) 

8 

Key 

Keyword 

To  be  determined 

Key 

Data  Base  (Acronym) 

To  be  determined 

Key 

Report  Title 

65 

Report  Number 

12 

Date  Issued 

14 

Page  Count 

4 

Security  Classification 

4 

Distribution  Status 

50 

Original/Revision 

8 

DNA  Call  Number 

11 

DDC# 

11 

4*  ihhi 


Documents  File  Logical  Structure 


1 

AD-A058  405  COMPUTER  SCIENCES  CORP  FALLS  CHURCH  VA  F/G  17/2.1 

INTEGRATED  NUCLEAR  COMMUNICATIONS  ASSESSMENT  DATA  BASE  EVALUATI— ETC (U) 

JAN  78  H A BLANK * P C WOOD*  J A CAMPBELL  DNA001-77-C-0115 

UNCLASSIFIED  CSC-4511-00300  DNA-4352T-1A  NL 


2qf2 

ADA 

058406 

■ 

jl 

if! 

pi  ill  i --f 

" 1 L 

L 

END 

DATE 

FIIWED 

!0  18 

DOC 

Record  Field  Definition 


Report  Title  - the  full  title  of  the  document 
Report  Number  - Contractor's  reference  number 
Date  Issued  - completion  date  of  the  document 
Page  Count  - number  of  pages  in  the  document 

Security  Classification  - classification  of  document  in  abbreviated  form 
(i.e. , (U)  for  unclassified) 

Distribution  status  - restrictions  as  to  distribution  of  documents 
DNA  Call#  = DNA  library  document  call  number 
DDC#  - DDC  reference  number 
DNA  Report  # - 

10.3.2.2  Contracts  Variable  File 

Descriptive  File  Name:  Contracts  File 
System  File  IName  - RVCN 

Purpose:  The  contracts  variable  file  contains  information  related  to  the 

Government  contracts  for  the  development  of  codes,  documentation,  etc. 
associated  with  nuclear  effects  on  communications.  This  file  can  be 
accessed  via  the  Code  Master  File  and/ or  the  Contractor  Master  File. 

Proposed  File  Content 

Data  Element 
Code  Name  (Acronym) 

Contractor  Name  (Abbrev) 

Contract  Number 
Responsible  Agency 
Responsible  Office 
Address 
Let  Date 
Completion  Date 
Performer 
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8 

8 

16 

4 

6 

15 

14 

14 

30 


Key 

Key 
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Record  Field  Definition 

Report  Title  - the  full  title  erf  the  document 
Report  Number  - Contractor's  reference  number 
Date  Issued  - completion  date  of  the  document 
Page  Count  - number  of  pages  in  the  document 

Security  Classification  - classification  of  document  in  abbreviated  form 
(i.  e.,  (U)  for  unclassified) 

Distribution  status  - restrictions  as  to  distribution  of  documents 
DNA  Call#  - DNA  Library  document  call  number 
DDC#  - DDC  reference  number 

10.3.2.2  Contracts  Variable  File 

Descriptive  File  Name:  Contrats  File 
System  File  Name  - RVCN 

Purpose:  The  contracts  variable  file  contains  information  related  to  the 

Government  contracts  for  the  development  of  codes,  documentation,  etc. 
associated  with  nuclear  effects  on  communications.  This  file  can  be 
accessed  via  the  Code  Master  File  and/or  the  Contractor  Master  File. 

Proposed  File  Content 

Data  Element 

Code  Name  (Acronym) 

Contractor  Name  (Abbrev) 

Contract  Number 
Responsible  Agency 
Responsible  Office 
Address 
Let  Date 
Completion  Date 
Dollar  Amount 


Byte 

8 

8 

16 

4 

6 

15 

14 

14 


Key 

Key 
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10.3.2.3  Experts  Variable  File 


Descriptive  File  Name  - Experts  File 
System  File  Name  - RVEX 

Purpose:  The  Experts  File  contains  a list  of  personnel  with  expertise 
regarding  any  category  included  in  this  data  base.  Listed  with  the 
name  is  the  location  and  telephone  number.  The  file  contains  keys  such 
that  the  file  can  be  accessed  by  the  Code  File,  Contractor  File,  and/or 
Keyword  File. 


Proposed  File  Content: 

Data  Element 


Code  Name 

Contractor  Name  (Abbrev) 
Keyword 
Personnel  Name 
Personnel  Address 
Personnel  Telephone  Number 


Bytes 

8 

8 

To  be  determined 
20 
35 
10 


Key 

Key 

Key 


Note:  Fields  for  Expert  File  are  self  explanatory. 

10. 3. 2. 4 Major  Cross  Reference  Variable  File 

Descriptive  File  Name:  Reference  File 
System  File  Name  - RVMC 

Purpose:  The  Cross  Reference  File  is  incorporated  in  the  Resources  Data 
Base  Design  to  accommodate  file  structure  for  a DBMS  (Data  Base 
Management  System)  that  does  not  provide  direct  inter-file  access. 
For  example,  TOTAL  DBMS  allows  direct  link  paths  from  Master  to 
Variable  Files  but  not  to  other  Master  Files.  The  cross  reference 
variable  file  therefore,  provides  link  paths  between  Master  Files. 
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The  cross  reference  file  will  provide  key  fields  which  contain  access 
keys  to  other  Master  Files. 


Proposed  File  Content 


Data  Element 

Bytes 

Code  Name  (Acronym) 

6 

Key 

Contractor  Name  (Abbrev) 

8 

Key 

Keyword 

To  be  determined 

Key 

Data  Base  (Acronym) 

6 

Key 

Note:  Data  items  can  be  included  after  each  key. 


SECTION  11  - CONCLUSIONS  AND  RECOMMENDATIONS 

11.1  CONCLUSIONS  - TASDB 

The  TASDB  will  centralize  the  data  repository  function  for  the  INCA  program  as 
well  as  ensure  the  quality  of  data  elements  used  in  technical  analyses.  Only  if  a strong 
data  base  management  philosophy  is  adopted  can  the  latter  be  assured.  Centralization 
reduces  costs  of  data  acquisition  for  new  and  continuing  INCA  participant  efforts.  As 
new  data  is  produced  by  analyses,  system  assessment  simulations,  etc. , it  will  be  fed 
back  into  the  data  base  system  for  other  references  (assuming  the  results  are  of  general 
applicability).  No  quantitative  cost  estimates  of  savings  were  made,  but  qualitative 
considerations  from  a field  survey  show  that  there  is  repetitive  expenditures  for 
similar  or  identical  data  collection  efforts  currently. 

Two  features  of  data  base  management  systems  application  are  the  common 
storage  of  redundant  data  elements  and  the  direct  links  between  related  records  of 
distinct  data  files.  The  former  reduces  storage  charges  for  INCA  data  while  the  latter 
reduces  CPU  charges  in  that  CPU  time  is  reduced.  Reduction  of  CPU  time  is  effected 
by  removing  the  data  file  sort  requirement  and  linking  related  data  records.  When  a 
request  is  made  for  one  data  element  or  record,  all  others  related  to  it  are  "instantly" 
located,  hence,  no  sort  of  other  files  to  find  matching  record  identifiers. 

Use  of  the  data  record  links  also  reduces  programming  efforts  since  sorts  and 
file  processing  are  reduced  or  eliminated.  As  well  the  data  base  itself  is  isolated  from 
the  application  programs  by  the  data  base  management  system.  Consequently,  no 
specific  I/O  programming  is  required  for  access  to  data  files  and  since  there  is  none, 
any  data  base  reorganization  will  not  impact  application  programs  (provided  the  data 
is  still  stored  somewhere;  not  deleted  in  anyway).  Reorganization  can  be  to  the  record 
level  and  still  maintain  this  advantage  of  no  impact  in  application  programs. 
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Therefore,  a DBMS  implemented  at  this  time  saves  INCA  program  monies  due 
to: 

• Reduced  data  collection  costs  in  the  future 

• Reduced  programming  efforts 

• Better  data  quality  (making  technical  analyses  more  useful  per  dollar 
expenditure) 

11.2  CONCLUSIONS  - RESOURCE  DATA  BASE 

While  the  advantages  of  a DBMS  system  apply  here  as  well  as  for  the  TASDB, 
further  commentary  is  applicable.  Redundant  analytical  efforts,  resource  location 
costs,  man-power  effectiveness  are  all  aspects  of  creating  a more  cost-effective  INCA 
program.  During  the  time  period  CSC  has  been  involved  with  the  INCA  program  and 
during  the  data  base  survey,  the  necessity  for  an  automated  management  information 
system  regarding  resources  and  relevant  prior  work  became  evident.  Composite  data 
files  were  selected  and  the  data  records  cross-referenced  in  order  to  create  an 
efficient  system  for  the  benefit  of  the  INCA  participants  and  ultimately,  the  INCA 
program  itself. 

11.3  RECOMMENDATIONS 

CSC  recommends  that  a final  cost -benefit  analysis  be  made  which  will  measure 
the  data  base  system  concepts  and  design  generated  against  current  and  future  INCA 
program  efforts.  This  is  not  anticipated  to  be  either  a lengthy  or  costly  study,  but 
rather  to  demonstrate  clearly  that  the  designed  data  base  system  is  clearly  cost- 
effective  to  implement  at  this  time  or  at  a later  point  in  time. 

Assuming  that  the  analysis  proves  it  is  cost-effective  to  make  this  INCA  program 
investment  and  at  this  time,  CSC  recommends  that  the  Defense  Nuclear  Agency  take 
strong  action  to  establish  the  INCA  Data  Base  System  at  the  time  frame  the  analysis 
shows  to  be  most  cost-effective,  be  it  immediately  or  a future  point  in  time. 
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We  make  this  recommendation  in  view  of  the  fact  that  the  Defense  Nuclear  Agency 
and  the  INCA  program  are  long  term  entities,  and  therefore,  will  be  substantially 
involved  in  repetitive  data  collection  and  analysis  of  the  identical  or  similar  data, 
differing  from  INCA  task  to  task  only  on  its  organization  and  usage. 
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APPENDIX  A 

PROTOTYPE  INCA  DATA  BASE  RECORD  FORMATS  & CODES 


Reference  was  made  In  the  report  to  the  Prototype  INCA  Data  Base  System,  as 
set  up  on  an  IBM-370 /155  at  the  Defense  Communications  Agency  in  Reston,  Virginia. 
This  appendix  provides  detail  on  the  record  formats  and  data  element  values  used  in 
the  Prototype.  Data  so  described  is  standard  according  to  DCA  Circular  310-65-1, 
Circuit/Trunk  File  - Data  Elements  and  Codes  Manual  of  the  Defense  Communications 
System  and  is  a subset  of  the  total  data  elements  in  that  file.  Distribution  between  the 
Prototype  Data  Base  System  and  this  file  is  that  the  former  is  a time  automated  data 
base  while  the  latter  is  a sequential  record  organization  of  a bookkeeping  nature  which 
requires  much  file  handling  compared  to  a data  base  system  for  access  to  related 
data  elements. 

Tables  A-l  through  A-6  show  the  record  format  for  each  of  the  four  master 
files  and  two  variable  files  in  the  data  base.  All  remaining  tables  illustrate  the 
content  of  the  fields  in  these  records.  Data  is  oriented  toward  the  CONUS-EUROPE 
portion  of  the  DCS. 

Table  A-7  and  Figure  A-l  shows  the  trunk  identifier  codes  and  the  meaning 
of  the  various  component  character  positions  in  the  identifier. 

Table  A-8  states  the  Trunk  Service  Availabilities  codes  used. 

Table  A-9,  In/Out  Flag  Codes,  was  a field  set  up  for  use  by  a circuit/trunk 
assessment  model  developed  for  the  Trunk  Allocation  Assessment 
Task. 

Table  A-10  Facility  Codes  states  the  standard  facility  codes  selected  for  use  in 
the  Prototype  Data  Base. 

Table  A-ll,  Command  Communications  Service  Designator  indicates  the 

definition  of  the  component  character  positions  of  the  Command  Communica- 
tions Service  Designator  (CCSD). 
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Table  A-12,  Circuit  Service  Availability,  indicates  availability  of  circuit 
for  use  as  per  standard  DC  A definitions. 

Table  A-13,  Routing  Applied,  indicates  the  specific  routing  policy  applied  to 
a given  circuit. 

Table  A-14,  Sites  Contained  in  Data  Base,  giving  a list  of  all  sites  loaded  into 
the  data  base  for  the  Trunk  Allocation  Assessment  Task  Groups,  Included 
are  state/country  codes,  the  facility  located  at  the  site,  abbreviated 
site  name,  location  and  geographies  co-ordinates. 

Table  A-15,  Link  Identification,  indicates  the  definition  of  the  component 
character  positions  of  the  Link  Identifier. 

Table  A-16,  Transmission  Media,  gives  the  media  codes  and  definitions  of 
these  transmission  media  included  in  the  data  base. 

Table  A-17,  Link  Code,  gives  the  code  and  definition  for  various  link  classifica- 
tions used  in  the  data  base. 


Table  A-l.  RMTB  Record  Structure 


no.  of  tracks 


Table  A-2.  RMCT  Record  Structure 


-----  - - 


-- 
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Table  A-3.  RMS1  Record  Structure 


of  tracks 


Table  A-4.  RMLK  Record  Structure 
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Table  A-5.  RVCT  Record  Structure 


Table  A-6.  RVTL  Record  Structure 


Figure  A-l.  Trunk  Identifier 


AREAS  1,  2,  and  9 - WESTERN  HEMISPHERE;  AREAS  7 AND  8 - DCA-PACIFIC 
AREAS  3,  5,  AND  6 - DCA-EUROPE 


Table  A-7.  Trunk  Identifiers 


First  Character:  DC  A Area  Code  in  which  trunk  is  originated  (See  Figure  A-l  of 
DC  A areas/codes  worldwide) 

Second  Character:  DC  A Area  Code  in  which  trunk  is  terminated  (See  Figure  A-l  of 
DC  A areas /codes  worldwide) 

Third  Character:  Agency  Providing  Trunk 

Code  Identification 

B Department  of  the  Navy 

C Joint  Army  and  Air  Force 

E Joint  Navy  and  Air  Force 

F Joint  Army  and  Navy 

G Joint  NCS  Agencies  owned  trunks;  e.g. , between  DoD  and  FAA, 

DoD  and  Dept,  of  State,  etc.  This  code  is  used  when  the  trunk 
is  being  provided  jointly  between  two  NCS  operating  agencies 
(DoD  being  an  NCS-ope  rating  agency) 

I Allied  Government  provided  - to  be  used  for  those  trunks  provided 

solely  by  Allied  governments,  owned  or  leased 

J Department  of  the  Air  Force 

M Trunks  owned  by  DoD  agencies  not  specifically  listed 

U Department  of  Army 

X Commercially  leased  by  Air  Force 

4 Trunk  provided  by  treaty  organization,  owned  or  leased  (NATO  only) 

7 Commercial  submarine  cable  or  satellite  system  (individual 

channels  may  be  leased  by  one  or  more  agencies) . Trunk 
identifiers  assigned  for  administrative  and  record  purposes  only 

Fourth  Character:  Type  of  Trunk 
Identification 

High-speed  time  division  multiplex  system  (150  baud  and  higher 
channel  subdivision) 

Speech  plus  system 


Code 

C 

I 
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J.. 


Code 

J 

M 

Q 

R 

S 


Low-speed  time  division  multiplex  system  (less  than  150  baud 
channel  subdivision) 

Microwave 

Submarine  cable 

Landline  cable 

Satellite  relay 


T Forward  propagation  tropospheric  scatter  (FPTS) 

X VFCT  system  not  provided  via  HF  systems 

Y VFCT  provided  via  HF  or  combination  HF,  wideband 

Z Composite  system  (nonsimilar  media) 

8 Non- DCS  satellite  trunk 


NOTE:  A composite  system  (nonsimilar  media)  is  a mixed  system  whereby  a 
combination  of  microwave,  tropo,  landline,  etc. , is  used  to  support  one  trunk. 
This  type  system  will  carry  a "Z"  type  trunk  code.  The  only  exceptions  are 
trunks  with  submarine  cable  (Q),  HF  (B),  or  satellite  (S)  transmission  media. 


Table  A -8.  Trunk  Service  Availability 
Identification 

Full  period  (18-24  hr/day) 

Six  hours  or  less 
Available  6-12  hr. 

Available  12-18  hr. 

On  call.  Activated  by  callup  from  either  trunk  terminal 
1 irsl  programmed  reroute 
Second  programmed  reroute 

On  call  caretaker  status.  Activated  only  as  directed  by  proper  authority 

On  call  hoi  standby 

Contingency 


f 


Table  A-9.  In/Out  Flag  Codes 


Code 

A 

B 

p 

Sw« 

D 

E 

F 

G 

H 

J 

K 

L 

M 

N 

O 

P 

Q 

s 

T 

U 

V 

w 

X 

Y 
Z 


Identification 

In  service 

5-minute  outage 

15-minute  outage 

30-minute  outage 

GO-minute  outage 

90-minute  outage 

Permanent  outage 

(available  for  future  assignment) 

In  service 

5-minute  outage 

15-minute  outage 

30-minute  outage 

GO-minute  outage 

90-minute  outage 

Permanent  outage 

(available  for  future  assignment) 

In  service 

5-minute  outage 

15-minute  outage 

30-minute  outage 

GO-minute  outage 

30-minute  outage 

Permanent  outage 

(available  for  future  assignment) 


Tune 
Period  1 


Time 
Period  2 


Time 
Period  3 
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Table  A-10.  Facility  Codes 


Army  Communications  Center 

Forward  Air  Control  Post 

Aeronautical  Station 

Armed  Forces  Network 

Army  Terminal 

Air  Force  Terminal 

Navy  Technical  Control  Facility 

On-Line  Relay  Facility 

Commercial  Communications  Interface 

CRITIC  OMM  Station 

Communications  Center 

Submarine  Cable  Head 

CINC  Atlantic  Fleet  (CINCANTFLT) 

Command  Post 
Crypto  Station 

Commercial  Satellite  (COMSAT)  Terminal 
Commercial  Terminating  Point 
Circuit  Tie  Point 

AUTODIN  General  Purpose  Terminal 

Gateway  Facility  for  Submarine  Cable 

Main  Distribution  Frame 

Microwave  Repeater  Site 

AUTODIN  Message  Switch 

NATO  Satellite  System  Earth  Terminal 

NATO,  U.S.  Element 

Operations  Center 

Overseas  Switchboard 

Patch  and  Test  Facility 

Army  Receiver  Station 

Radio  Terminal  (w/o  Technical  Control) 

Radio  Relay  Station 

Radio  Site 

Satellite  Relay 

AUTOVON  Switching  Facility 

Ship  Communications  Facility 

Supreme  Headquarters  Allied  Powers  Europe  (SHAPE) 

AUTOSEVOCOM  758  Switch 

Switchboard 

Defense  Satellite  Communications  System  Earth  Terminal 
Telephone  Company  Building 


ACA 

ACF 

AER 

AFN 

ATE 

ATF 

BFC 

BOR 

CCI 

CCM 

CCT 

CHD 

CIC 

CPA 

CRY 

CST 

CTD 

CTP 

DPC 

GTY 

MDF 

MRS 

MSU 

NTE 

NTS 

OCA 

OSS 

PTF 

RCE 

RLT 

RRS 

RSA 

SAT 

SCA 

SHC 

SPE 

SVT 

SWB 

SYT 

TBA 


Table  A-10.  Facility  Codes  (Cont'd) 


Code 

' 

Description 

TBD 

Command  Switchboard 

TCA 

Traffic  Control  Agency 

TCF 

Air  Force  Technical  Control  Facility 

TCG 

Army  Technical  Control  Facility 

TCL 

Technical  Control 

TCM 

Technical  Control  Facility  Limited  Capability 

TRS 

Transmitter  Site 

TXL 

Army  Transmitter  Station 

WWM 

World  Wide  Military  Command  and  Control  System  (WWMCCS)  Center 

ZAZ 

National  Military  Command  Center  (NMCC) 

Table  A-ll.  Command  Communications  Service  Designator  (CCSD) 


First  Character:  Agency  Code  (of  organization  requiring  the  circuit) 

B Department  of  the  Navy 

C National  Command  Authority  (JCS) 

D Defense  Communications  Agency 

J Department  of  the  Air  Force 

N DoD  Agencies  not  listed,  e.g. , DIA,  NSA,  DLA,  DNA 

O Host-country  - for  all  circuits  required  by  any  country  who  is  host  to  U.  S. 

U Department  of  the  Army 

Second  and  Third  Characters:  Purpose  and  Use  Code 

DJ  National  Military  Command  and  Control  Voice  Network 

DM  Emergency  Message  Automatic  Transmission  System  (JCS) 

DN  Critical  Intelligence  Communications 

DVV  USAFE  Headquarters  Command  and  Control 

KR  ANMCC  Network 

KX  NMCC  Teletypewriter  Network 

KZ  NMCS  Data  Transmission 

QA  MAC  Command  Control  Record  Communication  System 

QM  MAC  Command  Control  Voice  Circuits 

TL  Low-Speed  TDM  System  (below  150  baud) 

TP  Speech  Plus  System 

TX  VFCT  System 

TY  High-speed  TDM  System  (150  baud  and  over) 

UA  Command  User  Teletypewriter  Service 


UB  Common  User  Voice  Service 

Tin  ru'd  Airoricr'irrir'niv* /«ir\rr>r'r»'iw  irMno  rn>v,mi„<;,.ntinno 


Table  A-ll.  Command  Communications  Service  Designator  (CCSD)  (Cont'd.) 

UE  Common  User  Digital  Data  (excluding  teletype) 

UL  DCS  Automatic  Record  Communications  Network  Circuits 

UM  Special  Purpose  Network 

UU  DCS  Automatic  Voice  Network  Circuits 

WC  World  Wide  Command  and  Control  System 

YK  Sage  AUTOVON  Switched  Network 

Fourth  Character:  Type  Service  Code 

A Teletype  Service  other  than  DCS  Switched  Networks 

B AUTOVON  Access  Line 

C AUTOVON  Inter  switch  Trunk 

D Data  other  than  DCS  Switched  Networks 

E AUTODIN  Access  Line 

F AUTODIN  Interswitch  Trunk 

H AUTOSEVOCOM  Interswitch  Trunk 

L DSSCS  AUTODIN  Access  Line 

N AUTOVON  Access  Line  serving  an  AUTOSEVOCOM  subscriber  or  switch 

V Voice  other  than  DCS  Switched  Networks 

X Package  System  Channel  accounting  by  DCA 


Filth  through  Eighth  Characters:  Circuit  number;  blocks  are  assigned  to  area  centers 

and  certain  agencies 


IAAA-IZZ7 

BAAA-B999 

25AA-2599 

AAAA-A999 

FAAA-F999 


Manager,  NCS  or  GSA 
DCA  Hq. 

DIA  (DCA  Europe) 
DCAOC  A&E  DIV 
DCAOC  A&E  DIV 


RAAA-R999 

6N0A-6N99 

20AA-2499 

26AA-2999 


DCA,  reserved 
DCAOC  A&E  DIV 
DCA  Hq 
DCA  Hq 
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Table  A -13.  Routing  Applied 

Code  Meaning 

A Preferred  routing 

B Reserved 

C Nonpreferred  route  specified  by  user  to  meet  operational  requirement 

D Route  required  due  to  system  loading  criteria  of  optimum  route 

E Route  required  due  to  lock  of  equipment  at  certain  stations 

F Route  used  because  channel  fill  precluded  using  optimum  route 

G Route  used  due  to  user  required  DCS/non-DCS  interface  or  routing 

control  point 

H Route  used  due  to  required  comme rcial/DCS  interface  or  routing 

control  point 

I Route  required  by  engineering  technical  criteria 

J Temporary  exercise  circuit 

K Temporary  test  circuit 

L Temporary  peak  traffic  overload  circuit 

M Cost  effective  routing 


Table  A-14.  Sites  Contained  in  Data  Base 


ST 

FAC 

ABBREV 

LOCATION 

CRTY 

CODE 

NAME 

NAME 

COORDINATES 

NUMBER 

TY 

SHC 

A FLO  AT 

AFLOAT 

01 

2 Y 

t 

AFLOAT 

AFLOAT 

02 

UK 

tcf 

ALCDN  DRY 

AI.CONBUR  Y 

522  2 25  N 

0001 3 1 0 W 

03 

23 

C ST 

ANDOVER 

ANDOVFR 

44 3 90 ON 

0704700W 

04 

24 

rcF 

AN  DR  EW  S 

ANDREWS 

384839N 

0765202  W 

05 

24 

TRS 

ANNA  POLS 

ANNAPOLIS 

3859PON 

0763000W 

06 

5 1 

SCA 

AFLTNGTN 

ARLINGTON 

38550CN 

077100DW 

07 

IR 

C ST 

ASAD  ARAD 

AS ADABAD 

344700N 

0480700E 

08 

S P 

CST 

ASCEN5IN 

A SCENSION 

0757  00  S 

0142109W 

09 

FT 

SYT 

ASMARA 

ASMARA 

151900N 

0385500E 

10 

FT 

rcL 

ASMARA 

ASMARA 

15  1900  N 

0 385500E 

11 

G R 

TCF 

A TURNS 

ATHENS 

3 75  900  N 

0234  300  E 

12 

IT 

NTE 

A URF L T A 

AURELIA 

4 1 5 30  Ov 

0122300E 

13 

UK 

RFS 

BAPKW  AY 

BA^KWAY 

520600N 

0000300W 

14 

UK 

RRS 

BOTLYHLL 

BOTLFY  HILL 

511650N 

000000 3E 

15 

!JK 

RS  A 

BOVINGDN 

DOVINGDON 

51 42 34  N 

000324  3 W 

16 

sp 

CST 

BUT  TR  AGO 

BHTTRAGO 

4 1000  ON 

0033890W 

17 

r a 

TCF 

C DY  ER 

CAMP  DYER 

663700N 

061 1800W 

18 

34 

SCA 

CEDAPBPK 

CEDAR  BROOK 

394200N 

0745400W 

19 

UK 

RS  A 

chfl V5TN 

CHELVESTOM 

52 1 8 1 3 N 

0003200  W 

20 

p 8 

TCI? 

CH  YNNMTN 

CHEYENNE  MR  N 

384900N 

1044300W 

21 

03 

cri? 

CHYNNMTN 

CHEYENNF  MTN 

334  900  N 

1 044300W 

22 

C A 

CUD 

CLARNVLL 

CLARENVILLE 

494400N 

1 154700W 

23 

SP 

CHD 

CONIL 

CON  TL 

361600N 

0060500  W 

24 

tT 

TC  L 

C OI.TANO 

COLT ANO 

433925N 

0102432E 

25 

CA 

CHD 

COENRBRK 

CORNER  BROOK 

4 8 3 3 0 0 N 

0583  300  W 

26 

PO 

HTF 

CSTDCPHC 

COSTA  DA  CAPARTCA 

3 83  8 0 On 

009 1 300  W 

27 

UK 

TCF 

CROHGHTN 

CROHGHTON 

S15930N 

0011 123W 

28 

UK 

RS  A 

DAV  ENTRY 

DAVENTRY 

521248N 

00 1 0550  W 

29 

TU 

ATF 

DI YAR3KF 

DIY ARBAKTR 

37540  ON 

040 1 300E 

30 

ru 

SYT 

DIY  ARRKR 

DIYARB AKIN 

375400N 

0401  300  E 

31 

GE 

TC  L 

D NNRSBRG 

DON  NERS  BERG 

49363^4 

0075535E 

32 

6 1 

SCA 

DRANSVLL 

DR  AN  ESVILLE 

39000CN 

0771 900  W 

33 

GL 

TCF 

DYF  1 

DYE  1 

663  70  ON 

0530000  W 

34 

01. 

TCF 

DYE  2 

DYE  2 

66290  IN 

0461725W 

35 

GL 

TCF 

DYE  3 

DYF  3 

6 5 3 3 0 0 N 

0374200W 

36 

GL 

TCF 

DYF  4 

DYE  4 

6533O0N 

0374200W 

37 

TC 

TCP 

DYE  5 

DYE  5 

635734  N 

0224  3 1 6 W 

38 

VO 

KTE 

EG3F.MOEN 

EGGFMOFN 

39 

TU 

TCF 

ELM  A DAG 

ELM ADAG 

39570C  N 

0324100E 

40 

SP 

CHD 

ESTEPONA 

FGTEPON  A 

362600N 

0050800  W 

41 

54 

CST 

ETAM 

ETAM 

391500N 

0794S00W 

42 

GE 

NT  E 

EUSKRCHN 

EUSKIRCHEN 

504000N 

0064700  E 

43 

38 

Tfl  A 

FARGO 

FARGO 

465200N 

0964600W 

44 

GE 

TCF 

FFL  DRER  G 

FELDBERG 

501432N 

0082947E 

45 

GE 

ACF 

FELDBEPG 

FELDBFRG 

5 0 1 4 3 2 N 

0082  947  E 

46 

24 

MSU 

FTP  ETRCK 

FORT  DETRICK 

39260  nN 

0772100W 

47 

24 

SYT 

FTDFTRCK 

FORT  DETPICK 

3 92  6 C 0 N 

0772100  W 

48 

24 

TCG 

FTDETRCK 

FORT  DETRTCK 

392600N 

0772100W 

49 

24 

TCM 

FT  MEADE 

FORT  MEADE 

390600N 

0764  300  W 

50 

24 

TCG 

FTRTTCHI 

FORT  RITCHIE 

394400N 

P772500W 

51 

24 

HUM 

FTP  TTCHI 

FORT  RITCHIE 

394400N 

0772500W 

52 

SE 

A p N 

FRANKFRT 

FRANKFURT 

500700N 

0084100E 

53 

GE 

GTY 

FRANKFRT 

FRANKFURT 

5007  00  N 

0084100E 

54 

GE 

TCG 

FRANKFRT 

FRANKFU RT 

50 07 CON 

0084  100  E 

55 

GP. 

RS  A 

FRIOLZHM 

FR  lOLZHBIM 

56 

IT 

CST 

FnCINO 

FUCINO 

464900N 

01 04300  E 

57 

OK 

TCF 

FYLNGDLS 

FYLINGDALSS  MOOR 

542100N 

0004000W 

58 

3C 

SCA 

GL  FN  DTVR 

GLEN  DIVE 

4 7 0 8 0 0 N 

1044100V 

59 

UK 

CST 

3 NHLYPNN 

GOONHILLY  DOWNS 

500258N 

0051029E 

60 

44 

CHD 

GR  PEN  HI.L 

GREEN  HILL 

61 

GE 

NDF 

HEIDLDRG 

HEIDELBERG 

62 

GE 

TCG 

HEIDLBRG 

HEIDELBERG 

63 

UK 

SCA 

HILLN5DN 

HILLINGDON 

513800N 

0002600W 

64 

UK 

TCF 

HILLNGDN 

HTLLINGDON 

51380ON 

0D02609W 

65 

IC 

TCF 

HO  FN 

HO  FN 

64 1 4 3 n N 

0145750W 

66 

SP 

SCA 

H HMDS A 

HUM  OS  A 

402954N 

0031512E 

67 

A-20 


IBIS  PAGE  IS  BEST  QUALITY  FSA0?i§M£f 
ISOM  COPY  FURNISHED  TO  EQO 


Table  A-14.  Sites  Contained  in  Data  Base  (Cont'd) 


ST 

FAC 

ABBREV 

LOCATION 

CRTY 

CODE 

NAME 

NAME 

COORDINATES 

NUMBER 

CA 

CHD 

IN  DN HRBP 

INDIAN  HARBOUR 

068 

TU 

TCF 

KARATAS 

KARATAS 

069 

TC 

BFC 

K EFL  AY  IK 

KFFLAVIK 

070 

TC 

ccn 

KEFLAVIK 

KEFLAVIK 

071 

IC 

SW  B 

KEFLAVIK 

K EFL  A VTK 

072 

NO 

CTP 

KENITRA 

KENITRA 

341 R06N 

0063549  W 

073 

no 

NCE 

KENITR  A 

KENITRA 

341806N 

006354 9W 

074 

NO 

SW  B 

KENITRA 

KENITRA 

34 1 806  N 

0063549W 

075 

3E 

TCI 

KONGSTHI. 

KOENTGSTH'JL 

076 

CA 

CCI 

LRYFNKLN 

LADY  FRANKLIN 

683CC0N 

1 1 3 1 000  W 

077 

CA 

TC  A 

LDYFNKLN 

LADY  FRANKLIN 

683000N 

1131000W 

078 

PO 

SIT 

L AJ  ES 

L A>7  FS 

079 

PO 

TCF 

LAJES 

LAJES 

080 

14 

sir 

LAKEHRST 

LAKEHURST 

400200N 

0742 100  W 

081 

GE 

A TF 

LANDSTHL 

LANDSTHUL 

49250  ''N 

0073400E 

082 

GE 

SIT 

LAN  DSTHL 

LANDSTH1JL 

4925C0N 

0073400  E 

083 

3E 

TCF 

LANG  RKPF 

LANGERKOPF 

491804N 

0075 1 22  E 

084 

BE 

CST 

L ESS  IV E 

LESSI VF 

085 

UK 

BFC 

LONUON 

LONDON 

51 3 1 CON 

0000600  W 

086 

UK 

GTY 

LONDON 

LONDON 

513  ICON 

0000600W 

0B7 

UK 

rt  r 

LONDON 

LONDON 

5131  PON 

0000600  W 

088 

TU 

TCF 

NALATYA 

NALATYA 

089 

NO 

CST 

N ARR  AKCU 

N ARUAKECH 

090 

UK 

TCF 

NTLSH  HHT 

NARTLESHAN  HEATH 

521C00N 

0012000E 

091 

34 

CPA 

NCGUIRE 

BCGUIR  E 

092 

IT 

RRS 

NT  CORNA 

HOUNT  CORNA 

093 

GP 

TCF 

NTPARNIS 

nOUNT  PARNTS 

094 

SR 

TCI 

NTPATEPS 

PIOUNT  PAT  ERAS 

380358N 

02322 3 7e 

095 

IT 

SCA 

N TVFRGIN 

HOUNT  VERUINE 

405b0  ON 

0 144300E 

096 

IT 

TCL 

NTVFPGIN 

HOUNT  VEPGINE 

4 056  0 ON 

0144300  E 

097 

UK 

TCF 

HPNNDH  LL 

HORHOND  HILL 

573608N 

0C20200W 

098 

UR 

CST 

HOSCOW 

noscow 

5545  00  N 

0374200E 

099 

51 

SCA 

NOSE  LEY 

NOSELEY 

37280  ON 

077470°W 

100 

TT 

BFC 

N APL  FS 

NAPLES 

4 05000 N 

0 1 4 1 700  E 

101 

TT 

BOR 

NAPLES 

NAPLES 

405000N 

0141700E 

102 

ZZ 

SAT 

NATOIIIA 

NATO  TIIA 

103 

IC 

TCF 

NATOSITF 

NATO  SITE 

6205Cr'N 

0070  20  0 E 

104 

GR 

BFC 

NEAN  AKPT 

NEA  P1AKRT 

105 

36 

CTD 

N YORK  CY 

NEW  YORK  CITY 

404000  N 

0735000W 

106 

51 

BFC 

NORFOLK 

NORFOLK 

365400N 

0761800W 

107 

51 

CIC 

NORFOLK 

NOR  POLK 

3 6 5 4 0 0 N 

076 1 800  W 

108 

51 

NTE 

NORFOLK 

NORFOLK 

3654C0N 

0761800W 

109 

UK 

NT  F 

0 AKHANGR 

OAK  HAN  GEP 

504500N 

00  15000W 

110 

UK 

CUR 

OBAN 

OBAN 

5S3G00N 

004  3500  W 

111 

IT 

CUD 

PALO 

PALO 

41S6P0N 

0 1 26000  E 

112 

51 

Z AZ 

PFNTAGON 

PENTAGON 

3850P0N 

0770000  W 

113 

51 

CPA 

PENTAGON 

PENTAGON 

385O00N 

0770000W 

114 

51 

SVT 

PENTAGON 

PENTAGON 

385000N 

0770000  W 

115 

51 

OSS 

PENTAGON 

PENTAGON 

385000N 

077000UV 

116 

51 

SW  B 

PFNTAGON 

PENTAGON 

385000N 

0770000  W 

117 

51 

NTS 

PENTAGON 

PENTAGON 

38500r'N 

0770000W 

118 

51 

TBD 

PENTAGON 

PENTAGON 

3B500CN 

0770000  W 

1 19 

51 

ACA 

PENTAGON 

PENT  AGON 

385000N 

077000OW 

1 2 C 

51 

AWR 

PFNTAGON 

PENTAGON 

38500ON 

077OPO0W 

121 

51 

CRY 

PFNTAGON 

PENTAGON 

38500CN 

077000CW 

122 

51 

OCA 

PFNTAGON 

PENTAGON 

385000N 

0770000  W 

123 

51 

IIC 

PENTAGON 

PENT  AGON 

385000N 

0770000W 

124 

5 1 

TCG 

PENTAGON 

PENTAGON 

3 950C0N 

0770000  W 

125 

GE 

RRS 

PIRHASNS 

PI R HAS ENS 

491200N 

007  3600  E 

126 

GF 

TCG 

PTPH  ASNS 

P IRUASENS 

49 1 20  ON 

0073600E 

127 

42 

SC  A 

POTTSTWN 

POTTS  TOWN 

4 0 1 5 0 0 N 

0754  000  W 

128 

GE 

CST 

RAT  STNGS 

RAI5TINGS 

475408N 

C 110659E 

129 

GF 

SW  B 

R AHSTEIN 

RAHSTEIN 

130 

5F 

PTF 

RH  El NHAN 

RHEIN  HAIN 

500158N 

0083522  E 

131 

TC 

SW  B 

POCKV ILL 

ROCKVILLE 

132 

TU 

TCF 

SAHINTPS 

SAHIN  TEP^SI 

133 

FR 

CHD 

STHLRDRS 

ST  HI LA IRE- DEFIES 

46  3 1C  ON 

D0301O0E 

134 

Z7, 

S AT 

SAT  ELL  IT 

SATELLITE 

135 

GF 

TCG 

SCRWTZGN 

SCHWETZ I NGF  N 

136 

17 

CPA 

SCOTT 

SCOTT 

137 
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Table  A-14.  Sites  Contained  in  Data  Base  (Cont'd) 


ST 

FAC 

ABBREV 

LOCATION 

CRTY 

CODE 

NAME 

NAME 

COORDINATES 

NUMBER 

BE 

SPE 

SHftPE 

S PR H HQ  ALD 

PWRS 

EOR 

138 

BE 

SWB 

SHftPE 

S PR H HQ  ALD 

PW  RS 

EOR 

139 

GE 

HRS 

STCKSBRG 

STOCKSBORG 

140 

5E 

TCS 

STOTTS RT 

STOTTGART 

484  70  ON 

0091200E 

141 

S A 

CST 

TftlE 

TAIF 

21 1334N 

0403051E 

142 

IR 

RCE 

TEHERAN 

TEHERAN 

354200N 

0512900E 

143 

IR 

TCG 

TEOERAN 

TEHERAN 

354  20  ON 

0512900E 

144 

IR 

TEL 

TEHERAN 

TEHERAN 

354200N 

0512900E 

145 

GR 

CST 

THERHPYL 

THERHOPYLAE 

146 

GL 

ftER 

THOL  E 

THOLE 

763400N 

0684800W 

147 

34 

CUD 

TOCKERTN 

TOCKERTON 

393600N 

0742000W 

148 

IR 

DPC 

TORKHNDH 

TORKHAN  DEH 

149 

IR 

tcf 

TORKHNDH 

TORKHAN  DEH 

150 

ZV 

BCO 

ONDTHNDL 

ONDETERHINED 

LOC 

151 

ZV 

CCE 

ONDTHNDL 

ONDETERHINED 

LOC 

152 

ZV 

CCO 

ONDTHNDL 

ONDETERHINED 

LOC 

153 

ZV 

NCY 

ONDTHNDL 

ONDETERHINED 

LOC 

154 

ZV 

CCH 

ONDTHNDL 

nNDET  ERHTNED 

LOC 

155 

GE 

TCG 

V MHINGN 

VAIHINGEN 

484400N 

0090600E 

156 

GE 

WWN 

VAIHINGN 

VAIHINGEN 

4 84  4 0 ON 

0090600  E 

157 

11 

GTY 

NASHNGTN 

WASHINGTON 

38500  ON 

0770000W 

158 

38 

SCft 

WHEATLND 

WHEATLAND 

159 

36 

GTY 

WHITPLNS 

WHITE  PLAINS 

160 

OK 

CHD 

WIDEHOTH 

WTDEHOOTH 

504700N 

00433Q0W 

161 

TO 

TCP 

Y AHANLAR 

YAHANLAP 

162 

r 


Table  A-15.  Link  Identification 


First  Character: 

Type  Link 

Code 

Meaning 

B 

HF 

D 

Diffraction  radio 

H 

VHF/UHF  point-to-point  radio  relay 

K 

Cable  carrier 

L 

Leased  (leased  media,  any  type) 

M 

Microwave  radio 

Q 

Submarine  cable 

R 

Landline  or  cable  (includes  open  wire) 

S 

Satellite  relay 

T 

Forward  Propagation  Tropospheric  Scatter 

Second  through  Fifth  Characters;  Link  Number  Block  Assignments 

Code 

Meaning 

0000 

Assigned  to  commercial  links  that  do  not  meet 
the  criteria  for  link  number  assignment 

0001-0999 

DCA  Europe 

1000-2999 

DCA  Pacific 

3000-3999 

Western  Hemisphere 

4000-4999 

Headquarters,  DCA 

9000-9999 

Not  DCA  controlled;  our  own  number 

Table  A-16.  Transmission  Media 


Code  Description 

000  Unknown 

C01  CANTAT  Cable  1 

C02  TAT  1 Cable 

C03  TAT  2 Cable 

C04  TAT  3 Cable 

C05  ICECAN  Cable 

COO  SCOTICE  Cable 

C07  THULE  Cable 

C21  TAT  4 Cable 

C36  TAT  5 Cable 

C37  UK-Portugal  Cable 

C38  CANTAT  Cable  2 

C45  MAT-1  (Spain/Italy)  cable 

C48  UK-Spain  (Bilbao)  cable 

C49  TAT  6 Cable 

CAB  Government-owned  cable  nonloaded  (onbase  or  offbase  cable) 

CML  Commercial  lease  (media  not  specified) 

MXO  Microwave 

NOS  Nonsimilar  transmission  media 

SAH  Satellite  Intelsat  IV  F3 

SAJ  Satellite  Intelsat  IV  F7 

SWC  Satellite  (NATO) 

TSO  Tropospheric  Scatter 
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Table  A-17 . Link  Codes 


First  Character: 

Type  of  Link 

Code 

Description 

C 

Cable 

M 

Microwave 

N 

Not  specified 

S 

Satellite 

T 

Tropo 

Second  Character  is  an  alphanumeric  character  (0-9,  A-N,  P-Z)to  uniquely 
identify  the  link. 
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APPENDIX  B 

TUTORIAL  - FUNCTIONAL  ELEMENTS  OF  A DATA  BASE 


B.l  FUNCTIONAL  ELEMENTS  OF  A DATA  BASE  ARCHITECTURE 

In  this  section,  we  present  a brief  description  of  the  functional  elements  of  which 
a data  base  architecture  is  composed.  By  presenting  this  tutorial  section  now.  It  will 
aid  the  reader  unfamiliar  with  data  base  systems  In  understanding  the  detailed  system 
descriptions  for  the  INCA  Data  Base  System.  Included  are  the  four  major  functional 
elements: 

• Data  Sets 

• Links  (pointers) /chains 

• DBMS  software  package 

• Applications 

B.1.1  Early  Information  Systems 

Up  until  a few  years  ago,  data  processing  for  all  disciplines  was  characterized  by 
multiple  data  sets,  each  developed  for  only  one  or  a few  applications.  Often,  many  of 
the  data  elements  of  each  data  set  were  the  same.  Updating  one  data  set  meant  updating 
for  all  data  sets  (that  one  knew  of)  which  contained  the  updatable  elements.  Additionally, 
data  sets  were  kept  in  the  data  order  most  suited  for  the  given  few  applications.  To  use 
a related  data  set  would  mean  preprocessing  the  data  sets  into  a form  and/or  sort 
sequence  suitable  to  the  application.  Consequently,  the  same  data  elements  found  in 
many  data  sets  or  files  cost  extra  in  storage  costs,  updating  for  one  data  set  meant 
finding  the  other  data  sets  with  those  elements,  thereby  incurring  costs  in  extra  pro- 
cessing and  use  of  multiple,  but  differently  organized  data  sets  in  an  application 
execution  or  coding  different  I/O  for  each  file.  Additionally,  programmers/analysts 
had  to  be  aware  of  where  each  data  set  was,  what  was  in  it,  and  if  such  data  sets  were 
changed,  programs  had  to  be  changed. 
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Large  organizations,  such  as  manufacturing  concerns,  began  to  feel  the  burden  as 
computers  became  a major  element  in  the  organizational  framework.  Storage  costs  and 
processing  costs  required  optimization  for  cost-effective  data  processing.  Program 
changes  had  to  be  minimized,  especially  if  there  was  significant  programmer  turnover. 
Effects  of  changing  data  sets  on  various  applications  had  to  be  minimized  or  eliminated. 
Eventually,  the  concept  of  master  data  sets  evolved  in  which  data  of  a given  type  was  kept, 
(e.g. , payroll  and  personnel,  parts,  Invoices,  etc.).  Multiple  copies  were  not  allowed. 
Standardization  was  enhanced  by  software  which  would  access  as  many  files  as  required 
for  an  application.  Finally,  in  the  evolutionary  process,  the  concept  of  relating  the  data 
for  efficient,  rapid  access  was  conceived,  i.  e. , use  pointers  from  an  invoice  number  to 
records  in  the  parts  files  and  other  pointers  from  invoices  to  customer  account  records, 
back-order  records  in  their  respective  files.  Now  it  was  possible  to  read  a customer 
record,  follow  a pointer  from  that  record  to  another  record  which  might  be  in  the  invoice 
file.  Other  pointers  in  this  record  of  this  data  set  would  link  to  further  Invoice  records 
so  that  each  invoice  could  be  found  with  only  one  disk  access.  Pointers  In  Invoice 
records  would  link  to  records  in  the  parts  file  to  provide  descriptive  and  pricing  informa- 
tion such  that  parts  descriptions  and  prices  were  kept  in  exactly  one  place  and  stored 
only  once — in  the  parts  file. 

Maintenance  of  the  chains  of  pointers  (links)  was  crucial.  To  destroy  one  pointer 
In  a chain  was  to  lose  the  remainder  of  the  chain  and  consequently  destroy  the  value  of 
the  system.  A software  package  to  act  as  an  Interface  between  the  user  and  the  data  set 
links  (the  complex  of  data  sets  and  inter/lntra-data  set  polnters/chains  is  now  called  a 
data  base)  was  absolutely  necessary  and  software  firms  began  to  produce  such  Data 
Base  Management  System  packages  (DBMS).  With  such  a package,  four  objectives  are 
immediately  met.  The  data  base  with  its  critical  element  of  record  pointers  is  protected. 
Secondly,  the  programmer  need  only  pass  a data  request  list  to  the  DBMS  and  receive 
back  the  data  without  knowledge  or  worry  of  how  the  data  Is  stored  or  organized.  Third, 
the  data  can  be  re-organized  without  changing  the  applications  software  (particularly 
the  I/O  areas)  Fourth,  a data  element  usually  occurs  only  once,  implying  optimized 
storage  costs  and  requiring  only  one  place  to  update  the  element  when  It  must  be  updated. 
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data  changes,  logs  of  transaction,  organizational  discipline  over  data  quality  since  data 
is  in  one  place  under  one  management  authority. 


From  the  above,  we  see  that  application  of  a data  base  management  system  means 
application  of  two  elements  In  the  organization:  a physical  ordering  of  the  data  for  cost- 
effective  data  processing  operations  and  secondly,  a philosophy  of  data  management 
(l.e.,  data  will  be  centralized,  controlled  and  quality  maintained  by  one  management 
which  will  be  held  accountable). 

B.1.2  General  Architecture  of  a Data  Base  System 

The  tutorial  now  continues  with  discussion  of  the  functional  elements  and  illustrations 
of  their  relationships.  The  examples  used  will  focus  on  part  of  the  INCA  Resources 
Data  Base  which  is  the  data  base  system  used  to  inquire  about  resources  available  such 
as  codes,  documents,  contracts,  etc.  In  addition,  to  just  a single-level  inquiry  for 
information  on  say  a company,  one  may  want  all  INCA-related  documents  produced  by 
that  company,  etc.  This  example  will  illustrate  reduction  in  data  storage  costs  and 
then  show  inter-relationships  between  records  of  different  data  sets. 

B.  1 . 2. 1 Data  Sets  or  Data  Files 

The  terms  data  set  and  data  file  are  used  interchangeably  and  refer  to  the  storage 
group  of  a set  of  related  records,  e.g. , the  document  file  would  include  all  document 
records.  In  earlier  times,  one  would  have  picked  a major  key  category  such  as  "contractor" 
and  provided  in  the  contractor  record  fields  for  name,  address,  document  names,  codes 
produced,  etc.  Continuation  records  might  be  used  when  additional  fields  must  be  filled 
in  over  and  above  what  was  originally  allotted  or  variable  length  records  might  be 
employed. 
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In  the  newer  data  base  technology,  the  data  Is  divided  Into  smaller  files  or  data 
sets  in  which  each  file  contains  only  information  about  one  subject  area:  contractor  file 
would  contain  only  name  and  location  and  no  reference  to  contract  numbers,  documents 
produced,  etc. ; the  documents  file  contains  only  information  about  individual  documents. 

In  the  latter  example,  company  name  would  appear  as  the  authorizing  organization  for  the 
document.  Figure  B-l  illustrates  the  three  data  files  of  our  example.  It  also  shows 
that  the  contractor  name  and  address  appears  as  part  of  each  record  in  each  of  the  data 
files.  Under  contractors,  it  is  the  necessary  and  only  record  information  or  there 
would  be  no  contractor  file.  In  the  remaining  two  files,  it  is  required  ancillary 
information,  although  redundant  storage  is  required  for  the  full  name/address  in  each 
of  three  records.  Any  change  would  require  accessing  all  three  files  for  change  consis- 
tency. One  step  of  the  data  base  design  process  is  to  identify  such  redundancies  and 
replace  the  secondary  element  (in  this  case,  name/address  in  Document  and  Data  Set 
files)  by  a short  pointer  to  the  record  in  the  Contractor  file.  Now  there  is  exactly  one 
place  to  update  name  and  address  information.  Figure  B-2  illustrates  the  pointers  from 
the  two  data  files  to  the  Contractor  file. 

The  next  set  of  points  would  deal  with  relationships.  Chains  of  pointers  used  here 
are  primarily  to  speed  up  retrieval  activity.  Rather  than  select  a contractor  name  and 
then  search  the  entire  documents  file  for  those  with  that  contractor  name,  the  inquiry 
would  specify  "use  contractor  file  to  select  a contractor  and  list  all  documents  produced 
by  him". 

The  data  base  (made  up  of  the  three  data  files)  would  be  inter-linked  with  a pointer 
from  the  company  record  to  the  first  document  produced  by  the  company.  That  document 
record  would  be  retrieved  (e.  g. , for  printing)  and  then  the  pointer  field  in  that  document 
record  would  be  examined.  If  end-of-chain  Indicator  is  present,  there  are  no  more  docu- 
ments for  that  contractor.  If  it  is  a valid  pointer,  then  it  points  to  another  document  record 
for  that  contractor  elsewhere  in  the  Documents  file.  After  Its  retrieval.  Its  pointer 
field  is  examined  for  end-of-chain  Indicator  as  before.  When  there  are  no  more  documents, 
the  request  for  that  contractor  Is  satisfied.  Another  contractor  Is  selected  by  the  user 
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or  the  next  contractor  in  turn  is  taken  from  the  Contractor  file  if  all  contractors  are 
to  be  processed. 


A similar  pointer  system  exists  from  Contractor  file  to  the  Data  Sets  owned  by  that 
contractor.  Figure  B-3  illustrates  this  situation.  Other  linkages  such  as  from  Document 
file  to  Data  Sets  file  can  also  be  established.  This  would  simplify  requests  of  the  form 
of  "give  all  data  sets  related  to  a given  document. 

B.  1.2.2  Data  Base  Management  System 

Having  created  a data  base  with  a set  of  chains  presents  certain  porblems  in  the 
efficient  utilization  of  the  data  base.  If  a user's  applications  program  is  to  operate 
with  the  data  base,  he  must  be  aware  of  record  layouts,  pointer  chain  locations  in 
each  record,  nature  of  the  end-of-chain  pointer,  the  numbers  of  chains  and  how  to 
manage  them,  especially  if  he  will  add  records  or  delete  them.  Also,  there  is  a 
problem  of  someone  else  attempting  to  follow  a chain  and  read/write  data  in  records 
as  the  first  user  is  modifying  the  chains.  In  the  latter  case,  the  situation  could  arise 
where  the  second  user  reads  a record  in  the  chain  he  is  following  (pointers  included), 
updates  a value,  but  before  he  can  return  the  record  (with  unchanged  pointers),  the 
first  user  modifies  the  pointers  on  the  disk  copy  of  that  record.  Then  the  second 
user  gets  to  return  the  record  (with  the  pointer  values  he  read).  When  he  does  so, 
he  wipes  out  the  new  chain  pointer  placed  there  by  the  first  user.  The  chain  is  now 
defective  since  the  pointer  values  have  erroneously  been  reset  to  their  old  values  and 
the  record  may  not  point  to  the  next  record  in  sequence. 

Other  problems  include  the  fact  that  one  user  may  be  able  to  lock  out  other  users 
if  he  does  not  promptly  return  a record  he  read.  Users  might  update  fields  they  have 
no  authority  to  update.  There  is  no  central  software  module  to  log  transactions  for  use 
in  bringing  up  a crashed  data  base.  The  left  side  (bottom)  of  Figure  B-4  illustrates 
the  direct  use  of  the  data  base  by  application  programs. 
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Figure  B-3.  Data  Relationships 


To  correct  these  problems,  an  interface  package  called  a Data  Base  Management 
System  (DBMS)  is  employed.  It  Is  aware  of  all  record  formats,  data  files,  pointer 
fields,  etc.  It  can  control  access,  as  well  as  authority  to  make  modifications  to  chains 
of  pointers,  produce  a transaction  log  of  each  modification,  etc.  Additionally,  it  sequences 
multiple,  simultaneous  users,  ensure  that  one  user  does  not  lock  others  out  by  holding 
a record  longer  than  a preset  time  limit,  etc.  All  application  programs  make  calls  to 
the  DBMS  to  request  lists  of  data.  The  DBMS  will  obtain  the  records  or  fields  within 
records  and  fulfill  the  list  for  the  requesting  application  program.  The  application  program 
is  insensitive  to  any  data  set  or  record  format  changes.  Changes  to  existing  applications 
programs  are  required  only  if  the  data  elements  It  requests  are  no  longer  to  be  kept  in 
the  data  base  (which  may  make  the  application  package  obsolete  in  terms  of  the  organiza- 
tion work  since  the  removal  of  data  implies  it  and  the  program  are  of  no  more  value). 

Changes  to  the  data  base  (adds,  deletes,  etc. ) are  monitored  by  this  central  focal 
point  and  logged  to  tape/disk  for  use  in  case  of  a data  base  crash.  All  physical  changes, 
like  the  read/write  accesses,  are  actually  performed  by  the  DBMS  in  the  service  of  the 
application  program.  Therefore,  greater  data  base  Integrity  is  ensured  and  crashes 
are  less  likely. 

The  right  half  (bottom)  of  Figure  B-4  illustrates  the  use  of  the  DBMS. 

B.  1.3  Applications  Programs 

A data  base  system  is  not  complete  without  application  programs.  The  DBMS  is 
only  an  interface  package  which  can  accept  requests  from  othei  software  packages 
for  data  base  processing.  The  DBMS  has  no  provision  for  accepting  real-time,  batch 
or  RJE  inputs  from  a user.  Therefore,  application  programs  must  be  developed  to  make 
the  data  base  system  useful.  The  user  may  design  software  which  processes  certain 
data  without  input  (more  precisely,  the  input  is  part  of  the  program),  or  processing  soft- 
ware which  reads  cards,  tapes,  disk,  etc. , in  a batch  environment  to  select  the  processing 
desired.  For  terminal  inquiries,  a teleprocessing  monitor /inquiry  package  must  be 
provided. 
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These  are  generally  the  responsibility  of  the  user.  Some  vendors  of  DBMS  do 
offer  generalized  report  writers  and  teleproeessing/lnquliy  packages  for  the  user  who 
finds  these  will  fit  his  application. 


Application  programming,  when  using  a DBMS,  is  greatly  simplified  relative  to 
file  description  file/record  format  layout  coding  and  I/O  coding.  There  is  no  analysis 
or  system  planning  required  to  set  up  files— the  DBMS  controls  the  already  optimally 
established  data  files/data  base.  Coding  of  records  layouts  and  field  data  element  attributes 
is  eliminated  for  the  most  part— DBMS  has  such  attributes  already  established.  I/O 
coding  requires  only  passing  a list  of  data  elements  desired  and  the  DBMS  finds  the  data- 
no  programmer  coding  to  access  and  search  for  desired  data.  Records  related  to  the 
retrieved  data  (e.  g. , documents  related  to  a retrieved  contractor)  can  be  rapidly 
retrieved  from  the  second  file  without  the  programmer  having  to  perform  the  file  search. 

If  the  data  base  organization  is  changed  to  reflect  the  addition  of  new  files,  data  element 
interchanges  between  records,  record  layouts  modified,  the  application  programs 
generally  need  no  modification,  since  record  layouts,  file  descriptions  are  not  coded  in 
programs  using  a DBMS.  As  long  as  the  data  is  available  and  the  DBMS  remains 
unchanged  (with  regard  to  the  interface  between  the  DBMS  and  application  programs), 
application  software  is  insensitive  to  physical  data  file/data  base  changes. 
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